wasm backend js scripts malfunction when being installed as symlink
the wasm backend installs some js scripts in the global libdir that may either be invoked as a main program by `node` or be imported as a dependent module, so we used to use the following logic to distinguish whether the current module is invoked as main program:
```javascript
import.meta.filename === process.argv[1]
```
however, it turns out that this would return `false` when the main program is installed as a symlink; `import.meta.filename` would return the canonicalized filename, but `process.argv[1]` would return the symlink's name. this causes a problem for nix packaging involving `shellFor` where a wrapper libdir is created to include non boot libs, and the js files in the wrapper libdir are symlinked from the original ghc store path instead of copied. in which case, wasm TH/ghci would fail with `readPipe: end of file` since the iserv script falls through and exits immediately.
kudos to @ners @vkleen for getting to the bottom of this bug in our call today.
issue