toLeopard: Fixes and improved clarity for unique-name behavior

[towerofnix]

Development:

• Fixes toLeopard: Sprites named "Math" and "Date" break math and time blocks in their own scripts #133
• Fixes toLeopard: Script names can override certain (newer) important names #134
• Fixes toLeopard: Custom block named "constructor" breaks project generation #136
• Fixes toLeopard: "NaN" is a valid sprite name, and a syntax error! #139
• Resolves toLeopard: Sprites and the stage shouldn't share the same reserved name list #135
• Towards Deprecate sprite.vars.* in favor of using class properties directly? leopard#196

Addresses the stuff above! Notable details:

• We've moved these lists, still hard-coded, into top-level constants, rather than embedding them right inside the toLeopard function. This makes them more convenient to locate and edit, and separates particularly word-based data from actual conversion logic.
• We've updated and added new documentation strings to relevant top-level constants. These hopefully offer some improved clarity — particularly useful since these are important lists to keep maintained!
• We've renamed uniqueNameGenerator to uniqueNameFactory because generator functions and factory functions are different things, and this is the latter. (Best not to conflate with the JavaScript term "generators", especially since Leopard itself makes extensive use of JS generators.)
• We've improved some internal spot documentation. This probably belongs in the next PR, but it's just better describing the current state of the code, so...

Here's the big external change, besides the word-list fixes listed at the start:

• We're using separate reserved word lists, based on a common list, for the stage and sprites now. We've closely reviewed the current Leopard definitions of SpriteBase, Stage, and Sprite to make sure we're covering everything (and not leaving some crucial things only in the sprite list and not the stage list, for example). But a second pair of eyes comparing that code with this would be great, of course!

We have also introduced a new JS_RESERVED_PROPERTIES list. These are names you really don't want generated code to ever be messing with! This is mostly to cover our bases when we do variables on this. We technically won't ever hit __proto__ because that's not a camel-case name, and prototype is only meaningful on functions (which sprite instances aren't)... but constructor really does fix a bug (#136), and we figured better to be a little more comprehensive than less, in such a context-generic list.

[PullJosh]

Question: Do we want to blacklist browser-provided identifiers like Array, Audio, Error, File, Map, Set, Temporal, etc., which are not used in generated Leopard code but could cause conflicts or confusion when the user starts adding their own hand-written JS code?

There are a lot of them. And keeping up-to-date might be challenging.

[towerofnix]

Thanks, this is a good point! We've followed it up in detail here: #138

[PullJosh]

This looks nice! Thanks. 😄

I haven't properly tested the behavior, but the code looks good (aside from one comment with a requested fix). If you're reasonably confident that the behavior is correct, I'm happy with merging this and then maybe I can give it a proper test of my own after switching away from this.vars.* before publishing a release.

Or if you'd rather wait until I can really sit down with it, it'll just take a few days.

[towerofnix]

Oops! Thanks for that catch LOL.

We'd prefer that you take the time to check it out before we merge. It fixes some bugs and otherwise is a totally non-breaking release, so we'd kind of like to publish it as a separate version from the change for this.vars.* -> this.*. Of course we can work out any quirks while testing in general, and the current version will only be useful historically speaking, but it'd still be nice to have this validated and published as its own thing. (The last bastion of this.vars.* syntax, lol.)

No problem about the delay, by the way. Thanks to your blessing/look-over we can say this is a good base, so we can get started on this.vars.* -> this.* in a separate branch sooner, just starting from these commits.

[towerofnix]

Addendum for this PR: While we can generate the lists dynamically and certainly include a broader list of globals than just what sb-edit depends on accessing—we are still OK to start on implementations based on these top-level constants. Because, we'd just be changing how the lists are generated, not how they are externally accessed (still the same variable names that still represent the same practical contents, just better versions of those lists).

[PullJosh]

Tested and looks good! 😄 (Sorry for the delay)

[towerofnix]

No problem! We've been busy anyway LOL. 🥳 Thanks!!