Scopes: Update kind to be an arbitrary string in the names field

[jridgewell]

This changes kind from an enum of known values, to be an index into the names field holding any arbitrary string. This allows us to better accommodate non-JS languages.

[connor4312]

Some suggestion of standard name fields may still be useful here for clients, e.g. in types saying 'global' | 'class' | 'function' | 'block' | string, so that they can be presented nicely.

[jridgewell]

I updated to add these as suggested names.

[jkup]

Latest change looks good to me, I do like having the suggestions there.

[szuend]

Should the kind offset be relative to the preceding kind? (or absolute for the first start item). This would keep the number small if all scope kinds are grouped somewhere in names together.

[jkup]

We talked a bit about this during our monthly call. @rbuckton and @szuend are going to take a look and discuss the benefits/cost of relative vs. absolute offsets for these.

[rbuckton]

Absolute vs. relative offsets for kind is only as efficient as the source map generator makes it.

If a generator adds a names entry for a new kind on-demand, it's less likely to be in sequential order, and could theoretically result in an index that requires a 2+ character Base64VLQ encoding.

If a generator is able to preload all names for kind in advance to keep them sequential, but may have already added entries to names (say, due to concatenating multiple inputs into a generated output), the initial kind is only as efficient as the current names count, which could be large enough to require a 2+ character Base64VLQ encoding.

If a generator is able to preload all names for kind in advance to keep them sequential, it may as well do so for all inputs and stuff them at the front of names, then it would only be as efficient as the total number of names entries it needed to add.

In the meeting, I was under the mistaken impression that a relative kind would mutate the counter for names, but that is not the case as the kind offset is tracked independently. After giving this more thought, it does seem like a relative kind makes the most sense. An efficient generator will pack all kind entries at the front of names. With a relative kind, the indices [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16] would be encoded like "ACCCCCCCCCCCCCCCC" (17 characters), while a non-relative kind would be encoded like "ACEGIKMOQSUWYacegB" (18 characters). For fewer than 17 entries there is no difference in the size of the encoded output, but for 17 or more entries, a relative kind can be more efficiently encoded and stored.