Editorial: convert to ecmarkup

[nicolo-ribaudo]

This PR migrates our spec from Bikeshed to Ecmarkup, trying to keep the changes between the two versions as minimal as possible (i.e. only where we use some bikeshedisms that do not work with Ecmarkup).

I still need to make GitHub pages work, but for now you can:

1. Clone this branch
2. Run npm ci
3. Run node --run build or node --run watch
4. Serve the out folder and open it in the browser

This PR unlocks possible improvement, such as @szuend's grammar-based VLQ parsing definition, but they will be done in follow-ups.

Preview: https://nicolo-ribaudo.github.io/source-map/branch/ecmarkup/

[takikawa]

This looks great, thanks for doing the conversion! I left some comments about small issues, LGTM other than those.

[szuend]

This does indeed look great! I only have small concern that we tie decoding very closely to Ecma262 language semantics.

E.g. we could spec decoding of mappings as syntax directed operations over a grammar like

<emu-grammar type="definition">
  Mappings :
    `;` Mappings
    MappingList Mappings?

  MappingList :
    Mapping
    MappingList `,` Mapping

  Mapping :
    GeneratedColumn
    GeneratedColumn OriginalSource OriginalLine OriginalColumn
    GeneratedColumn OriginalSource OriginalLine OriginalColumn Name

  GeneratedColumn : Vlq
  OriginalSource : Vlq
  OriginalLine : Vlq
  OriginalColumn : Vlq
  Name : Vlq
</emu-grammar>

then we wouldn't need to use String.prototype.split.

We can do that as a follow-up though to get us started.

[nicolo-ribaudo]

I pushed an update that still relies on ECMA-262's data types, so that we don't have to re-define them, but it only uses its basic version of objects (https://tc39.es/ecma262/#sec-object-type), without all the special behavior that JS supports on top of it. I also define a "JSON object" and "JSON array", which we can use across the specification rather than referring to ECMA-262's object (a JSON object is more restrictive, because it guarantees that it's deeply JSON-compatible).

The way those utilities read properties from the object (Let _prop_ be _object_'s own property whose key is _key_) is the same used by ECMA-262 to interact with its Object type at the most fundamental level (e.g. https://tc39.es/ecma262/#sec-ordinarygetownproperty).

I also redefined string.split: we'll probably not needed it once we do Simon's grammar suggestion, but for now it avoids having to go read how string splitting works in ECMA-262.

(trying to get the preview to auto-update...)

[takikawa]

I looked through the latest changes wrt ECMA-262 datatypes and left some comments. Otherwise the new changes LGTM.

[szuend]

Very nice! Thanks!