[FIX] Fix class name parsing for some objects

[NotHyper-474]

Note

This PR now fixes some class types getting parsed to "Object" as if they were anonymous structures. You can still check out the original description below.

Original Description

https://github.com/larsiusprime/polymod/blob/7f82ddb3e11e33ad0dd42e0c3e1417edc90e38f9/polymod/hscript/_internal/PolymodInterpEx.hx#L1124-L1125

This snippet will convert any object to a string; some anon structures can contain string maps in them which will allocate memory when those are converted to strings when getting or setting a value. One a lot of mods seem to reference is FlxG.save.data which can contain a lot of string maps, causing very frequent memory allocations.

memory-leaky.mp4

Since a TObject can be either a class type or a struct I was compelled to either:

• Use Type.getClassName (which is apparently slow even though all it does is access a field behind the scenes? Not saying it is, I just heard it from someone)
• Take advantage of the fact Polymod has to resolve classes from imports and when initializing objects, and so store these classes in a map along with their names. (Shout out to Kolo for the idea)

I decided to go with the second since getClassName has so much hatred. I haven't had the chance to test it thoroughly but testing the blacklist of FlxSave.resolveFlixelClasses (static) and FlxSave.data (instance) and both worked, and the memory leak disappeared.

[EliteMasterEric]

Since I fixed TObject to return String, the only thing this PR does is provide some caching for certain known types, right? What do you mean by TObject sometimes being a class type?

[NotHyper-474]

Since I fixed TObject to return String, the only thing this PR does is provide some caching for certain known types, right? What do you mean by TObject sometimes being a class type?

Yeah, I guess. All the cache is for is to store the names of classes returned by Type.resolveClass which will always be of the type TObject for some reason (perhaps it's a Haxe bug?), and you can see that's the case here.
And all this is to avoid having to use Type.getClassName, unless you would actually be fine with that.

[EliteMasterEric]

I just looked at the code internally, and all Type.getClassName does on C++ is access a string value on the class object.

Not sure what any performance issues would be with that, so if we could use that instead and remove the extra code that would be nice.

[NotHyper-474]

I just looked at the code internally, and all Type.getClassName does on C++ is access a string value on the class object.

Perfect, that was exactly what I was confused about. I thought the whole ordeal of using Type.typeof was to avoid using Type.getClassName but I also don't think it has any impact on performance at all. I'll be making the suggested changes.

[NotHyper-474]

oh, whoops lol