[HELP WANTED] A pseudo HScriptedClassMacro rewrite

[KoloInDaCrib]

This PR somewhat rewrites HscriptedClassMacro to work on almost every class. In other words, it makes every class extendable, as opposed to relying on classes that have the @:hscriptClass metadata and implement the HScriptedClass interface.

By technicality it is not a full-on rewrite, as it borrows a lot from HScriptedClassMacro, though there are a couple of notable tweaks to utilize the fact that every class is modified:

1. Instead of creating two new functions per function from the base class and its superclasses, it instead modifies the expression of every function of the base class to first point to the abstract script class (if it exists) before referring to a newly created function with the original expression. This is done for the superclasses as well so there isn't any need for additional functions.
2. Every instance of the @:allow metadata that would only allow a single function to access the underlying field or class gets changed to allow the entire class the access. This is done because we cannot guarantee that the proper functions will be generated due to the class potentially being incompatible with the macro.
3. Likewise, every instance of functions being called with inline in the manner of inline func(); get changed to remove the inline, as functions that first check through _abs don't have a final return.

All of these processes are only done in the macro context to not slow down the compilation server (at least in theory, since I don't really use intellisense so I can't verify)

Though there are two hurdles that prevent me from opening the PR:

1. Adding _asc fields to classes that are used by json2object throws an error, since they would need to be serialized. To circumvent this, I temporarily added the @:jignored metadata to every created hscript variable, but I would prefer a solution that's a lot more user-friendly as Polymore isn't meant to be Funkin' exclusive to my knowledge.
2. Since the created __super_ functions retain their access, there's instances where a function is declared as override, even though the compiler can't detect a function it overrides. In hopes of fixing this, I made it so that it removes AOverride from the access array if that's the case, though now the game refuses to compile with an error that points to an .ml file (so the literal source of haxe....yikes!), at least on hashlink. Not sure if this also happens on other targets. A good example of classes that are like this are the Layout classes from haxeui-core, presumably because they're created with a macro??? But then again thesame thing happens with some flixel classes...

I have been trying to fix the 2nd hurdle for weeks now, but it's starting to become hell and draining, so I didn't want to gatekeep this PR anymore in hopes that someone has any desires to look into this.

[EliteMasterEric]

Ah interesting, you're basically auto-generating classes that implement HScriptedClass for every class in the repository, then trying to clean up the remaining issues...

Could you potentially make this PR multi-stage, by implementing your improvements into the HScriptedClass macro and only running your new fixes on classes with @:hscriptClass on them, and then make fixes for other classes later?

[KoloInDaCrib]

Ah interesting, you're basically auto-generating classes that implement HScriptedClass for every class in the repository, then trying to clean up the remaining issues...

That's not really the case. What I'm doing in this PR is applying a @:build metadata to every class that haxe found, doing a bunch of checks and then doing necessary modification to the class and its fields to make sure that they could be extended by the scripts. There's no class generation involved as I feel like that would clog up the executable way too much.

Could you potentially make this PR multi-stage, by implementing your improvements into the HScriptedClass macro and only running your new fixes on classes with @:hscriptClass on them, and then make fixes for other classes later?

Unfortunately, no. The improvements to HScriptedClassMacro are heavily tied to the rework. For example, the change of how function overriding is implemented (only generate one function and override the expression of the other one) depends on there already being fields in the class to modify, which isn't the case for the current system. Classes that are extendable in it usually don't have any fields, since they're populated by HScriptedClassMacro.

Think of this PR like the lemz1 one which also aimed to rework how script class bases worked, though without the issue of no backwards compatibility.