The `ModuleList` used by the collector pass is now no longer re-used in
the VM backend, but instead translated to a custom representation (see
`produceModules`).

In addition, the list with the top-level AST is now discarded after it's
passed to code generation, which should reduce memory pressure, and thus
peak memory usage, quite a bit.

Extend the set of routines for interacting with `Store` and `SeqMap`.

Store the modules in a `SeqMap` with their position as the key. This
conveys intention better and leaves it to the consumer to use a more
fitting structure/representation.

For the internal representation, `vmbackend` uses a `Store` for the
list of modules, which makes the intention more clear and querying the
list a bit more ergonomic.

Much like how it works for the VM backend, the C backend now also uses
an orchestrator (the new `cbackend` module) that invokes the code
generator.

The `passes` integration (`myOpen`, `myProcess`, and `myClose`) is
removed from `cgen`. Setting up the extra header backend module (used
for C header generation) is now the responsibility of the orchestrator.

Similar to `vmbackend`, the new `cbackend` also operates on the
semantically analyzed AST of the whole program.

The upcoming C code-generation orchestrator needs access to the
`IdGenerator` for each module. They're now stored with `FullModule`,
allowing the orchestrator to retrieve them later.

`vmbackend` is adjusted to make use of the module's `IdGenerator`, which
is more precise than using the `ModuleGraph`'s one. Ideally, the backend
should not introduce any new symbol and type instances (which is what
the `IdGenerator`s are required for), but `transf` currently
necessitates that.

Since code generation now only takes place *after* the whole program was
semantically analyzed, forwarded procedures and unresolved borrows no
longer reach there.

Disabling stack-traces for the system module and all modules it imports
differs from what the C code-generator does (stack-traces are only
disabled for the `system` module there, but not for the ones it
imports).

The required access to `PGlobals` via `g.backend` is also a small
problem for upcoming `jsgen` refactoring.

Very similar to the introduction of an orchestrator for the C code-
generator, but for the JS code-generator.

The `passes` integration is removed form `jsgen`, and writing the module
to disk and generating the source map moved to the orchestrator.

The pass should only collect the statements into a list, and not
introduce its own decision making.

Instead of extracting the `ModuleList` as part of `generateCode`, it is
now passed in as a `sink` parameter. This:
* makes it easier to move away from storing the `ModuleList` as part of
  the `ModuleGraph`
* moves the mutation to the callsite
* allows for implementing the memory consumption optimization employed
  by `vmbackend` (which is eventually going to be used for the other
  backends too) in a much cleaner way

With code generation now always happening after all semantic analysis is
done, option changes applied via the `push` and `pop` pragmas no longer
apply to top-level statements.

As a temporary solution, the feature could be made to work by processing
`nkPragma` nodes in the orchestrators, but the planned upcoming changes
would render this approach unusable again.

Thank you for the review, @saem .

The comment was misleading, as a backend module is not closed for
writing after the call to `finalCodegenActions`.