Generate subclasses

[sparr]

As discussed on Discord, this is my first attempt at generating subclasses.

Anywhere the json docs for an attribute or method have a subclasses field, we currently just note that in the docs, the same way the official html docs do, e.g. "Can only be used if this is Ghost, CombatRobot, HighlightBox, SmokeWithTrigger or Sticker". This PR changes that behavior to instead generate new classes. Instead of one LuaEntity with dozens of "Can only be used if..." fields and methods, we have LuaEntity.base with the parts that are not specific to any subclasses, and new classes such as LuaEntity.Spawner and LuaEntity.CombatRobot with the subclass-specific parts. Then to wrap it all up the original LuaEntity identifier is now an alias that unions all the subclasses with the base class, similar to how variant_parameter_groups are currently handled.

Notable places to look in the generated output are LuaEntity, LuaEntityPrototype, LuaGuiElement, and LuaGuiElement_funcs, although the effects are wide reaching.

---@alias LuaEntity (LuaEntity.Spawner)|(LuaEntity.Unit)|(LuaEntity.ProgrammableSpeaker)|(LuaEntity.Character)|(...|(LuaEntity.base)

---@alias LuaGuiElement_funcs (LuaGuiElement_funcs.drop-down)|(LuaGuiElement_funcs.list-box)|(LuaGuiElement_funcs.tabbed-pane)|...|(LuaGuiElement_funcs.base)

I haven't done a thorough test or diff between the old and new generated output. I'm posting this before I fall asleep in case there's useful review feedback I can act on when I pick this back up soon.

I'm also not sure I like the way the _funcs naming scheme ends up with subclasses.

[sparr]

I have identified a failure mode.

Fields and methods with "subclasses": "TransportBeltConnectable" need to be available on belt, splitter, etc. This relationship is codified in the prototypes api as follows:

"name": "TransportBeltPrototype",
"parent": "TransportBeltConnectablePrototype",

The obvious approach which would work in this scenario but may break or produce inaccurate results in other scenarios would be to map runtime LuaFoo or LuaFoo.base or LuaBase.Foo to prototype FooPrototype, then get FooPrototype.parent e.g. FooParentType, then map that back to runtime LuaParentType. I am investigating / considering / discussing on Discord whether and how to potentially follow this relationship safely and reliably.

[sparr]

I'll try to revisit this with 2.0, and am open to any feedback before that.