All relevant tests are passing and a stub for FS functions is provided
when running in an environment without Node `fs` module or compatible.

  - Fix skip condition in tests that should be run under normal Go.
  - TestNativesDontImportExtraPackages loads original packages with
    `js/wasm` build target.

  - Skip tests that rely on GC finalizers.
  - Skip tests that rely on exact function names in stack traces.
  - Tweak goroutine leak detection to work with GopherJS stack traces.
  - Use fake networking transport for http client tests under nodejs.

…sts.

The removed packages either actually pass all tests, or skip
incompatible tests for `js/wasm` by default, which generally suits us
well.

Use the wasm implementation from the standard library instead. It has
more features and supports browsers with streaming unavailable. We still
keep `XMLHttpRequest` transport in case GopherJS users rely on it.

Most GopherJS users target browser and likely don't want to pay the cost
of file system polyfill they can't use in a browser anyway, so
minimizing it is worth the effort.

In addition, I converted the polyfill into  ES5 syntax, since we haven't
formally abandoned it yet.

GopherJS will use this target going forward. The values where chosen by
the following logic:

  - GOOS describes the targeted API environment, which is generally the
    same as when building wasm: both execute under a browser or nodejs.
    Build tag `js` is shared by GopherJS and wasm and can be used to
    target the general environment.
  - GOARCH describes the low-level emitted code, which is currently
    EcmaScript 5. Using `ecmascript` here differentiates from `wasm`,
    while not referencing GopherJS explicitly. It also leaves us a
    different paths for future upgrades to ES6+ by either changing
    GOARCH or keeping it and making this change implicit.

At the same time, we use fixed js/wasm target when building standard
library packages, which resolves a lot of concerns discussed in
gopherjs#693. Using js/ecmascript is
not feasible because it'll require us to maintain a lot more overlays
and/or rewrite build tags, which leads to the exactly same outcome.

In addition, we always set `gopherjs` build tag to make it easy to
guard sources using GopherJS-specific features. This is similar to `gc`
and `gccgo` build tags respective compilers set.

This change is potentially breaking for users that may have relied on
GOOS=linux in their sources. To make transition easier for them, we
support using GOOS/GOARCH from environment. However, they will be only
applied to the user code. Standard library will still be built with
js/wasm.

GopherJS doesn't support CGo. This was originally enabled to address
gopherjs#215 by providing a better
error when attempting to build a CGo package (instead of a compiler
panic). However, this approach makes GopherJS refuse to build packages,
which have a CGo and purego versions guarded by the `cgo` build tag:
GopherJS woudl try to load the cgo version and error out.

After this change GopherJS won't attempt to load Go sources with `import
"C"`, and it will load sources with `//go:build !cgo` instead. For
packages that require CGo one of the following errors will be returned:

  - "No buildable sources" if all Go sources import C.
  - "Undefined symbol" for symbols defined in the Go sources that import
    C and that are referenced by other Go source files.
  - "Unknown import path C" if you try to `gopherjs run` a source with
    import C directly.

To make transition somewhat less dramatic, we can provide the old
implementations for `syscall.Syscall` and its friends in case someone
actually wanted to make arbitrary syscalls from GopherJS running under
Node. I can't really think of any valid reason to, but who knows?

To enable this, a `legacy_syscall` build tag must be passed to GopherJS.
This shim is mostly intended for non-standard library code that was
using syscall package directly and it is more restrictive than
previously (e.g. the set of `syscall` functions still remains that of
`js/wasm`), but this seems like a reasonable compromise between
complexity and flexibility.

I am fairly confident that our support for file system access and a few
other syscalls, emulated via Node APIs is more than sufficient for all
our users, so after a release or two we will be able to delete this code
path entirely.

We could remove our overlay entirely, but our implementation seems to be
more advanced than the one of `js/wasm` in the standard library, so we
keep it for now.

We only build standard library for `js/wasm` now, which works for us
as-is, except for a couple of `go:linkname` directives we need to keep.

After we switched to building standard library for the `js/wasm` target,
some of the overlays we had to maintain for other GOOS values are no
longer necessary:

  - `crypto/x509`
  - `debug/elf`
  - `internal/syscall/linux`
  - `internal/testenv`
  - `net`
  - "noat" implementation of `os.RemoveAll`.

  - Reduce code duplication.
  - Ensure that it uses the same loading context as the compiler.
  - Ensure it uses the same test variants of packages as the compiler.

They were used as a side channel to extract GOROOT and GOPATH from
`build.Session`, which is an incorrect use of options. Eventually all
logic that requires these paths should be moved to the `build` package,
but for now we just provide an additional method to create a source
mapping callback.

Embedded file systems use unix-style slashes, which was causing errors
on Windows, when two styles were mixed. Converting all VFS paths to
unix-style slashes resolves the issue.

Fixes gopherjs#1049.

There are environments like AMD, which expose `require()` function, but
do not provide `fs` module. In such cases we should fall back to our
stub (see gopherjs#693 (comment)).

Ideally we'd do the complete set of tests, but there is a fair amount of
edge cases fixing which would require a significant effort. For now we
simply ensure that GopherJS can build, run tests and passes its own
tests.

See gopherjs#1111.

Co-authored-by: Jonathan Hall <flimzy@flimzy.com>