Store all locs associated with symbols in lookup tables, with `TSym.loc`
only being queried (but never written) for the external name or user-
provided flags.

In order to efficiently associate a `TSym` with a code-generator `TLoc`,
each `TSym` stores a one-based index (`locId`) into one of the code
generator's lookup tables. A table-based approach would have too, but
it's slightly slower (~1.4% when building the compiler itselfs).

In general, `cgen` becomes more strict with locs, now requiring globals,
constants, and parameters to have their loc set-up once at definition
processing time. Procedures, fields, and locals still need to
support ad-hoc loc setup.

Other changes:
- writing the mangled names to NDI files is temporarily disabled
- in symbol definitions contexts, `loc.t` is replaced with the querying
  the symbol's type directly (both are equivalent)
- locs for constants now store a symbol node in their `lode` field

Use a `Table` to map symbols to the corresponding JavaScript name,
which removes all modifications of `TSym.loc` from `jsgen`.

Due the lesser complexity of the JavaScript code generator compared to
the C code generator, a table-based approach works well enough.

`TType` doesn't need a `TLoc` field at all, and `TSym` only needs to
store the external name (`extname`) plus the interface flags
(`locFlags`).

The `TLoc`, `TLocKind`, and `TStorageLoc` types are moved to `cgendata`,
with `TLocFlag` staying in the `ast` module for now.

The orchestrator is now responsible for writing the mangled names to the
NDI files.

This is made possible by them no longer requiring access to an NDI
file.

It stored in the name slot the symbol of the method that the dispatcher
was derived from, which now causes problems. With the fix, for all
routines reaching the backend, `sym.ast[namePos] == sym` *should* be
true.

Co-authored-by: Saem Ghani <saemghani+github@gmail.com>