Editorial: add a 'decode a list of base64 VLQ' algorithm

[szuend]

This PR extracts a 'decode a list of base64 VLQ' algorithm that consumes a string wholly and returns all contained VLQ numbers as a list. We can share this algorithm between decoding mappings and originalScopes/generatedRanges of the scopes proposal.

It also makes the algorithm slightly more readable as we can get rid of position and we don't necessarily need the relative* variables as they only have a single use-site.

[jridgewell]

Can we keep the optional error for a non-1/4/5 length segment?

My code will be slightly out of spec since we'll eat the , as a 0 value and continue reading values from the next segment. I see if I can instead limit my position to < commaIndex without adding more checks.

[nicolo-ribaudo]

@szuend If you still need this PR for scopes, could you do what Justin suggested above (to avoid introducing observable changes) and rebase?

[szuend]

The decoding algorithms for scopes are very unwieldy, and having the format implicitly defined by a decoding algorithm makes it very hard to understand.

I'm wondering if we should go a different route and follow ecma262: Define the encoded format as a grammar and use syntax-directed operations for turning the grammar rules into structs. Ecma262 doesn't spell out a parsing algorithm after all where-as we do that currently in the source map spec.

[nicolo-ribaudo]

ECMA-262 doesn't define parsing algorithms, however it has "syntax-directed operations" to convert an "AST node" into an actual value.

For example, when some JS code contains 12.345, it is parsed implicitly according to the grammar but then it has some explicit recursive algorithms to tell that the token 12.345 represents the number 12.345: https://tc39.es/ecma262/#sec-numericvalue

We could do something similar.

EDIT: You wrote exactly what I suggested, sorry 😅 Yes, we could try doing that.