Refactor SceneManager / Transform; fix a number of bugs in scene/game object traversal

[mitchell-merry]

Another one of the changes I made to asr that I need to upstream...

Why?

I'm now more and more often traversing the gameobject tree in my autosplitters. This has culminated in being able to get a field on a component of a gameobject in a scene: https://github.com/mitchell-merry/autosplitters-wasm/blob/94fbcef38134317b3a5bd7e549a483f18bed17c4/cuphead/src/memory.rs#L170 which does wonders for what's possible.

I have been maintaining a fork with a bunch of tweaks to asr to make this possible, and it's about time I upstream some of it.

• Concepts of Scene/SceneManager and Transform/GameObject are a little too interwoven
  • I wanted to access GameObject#activeInHierarchy, but it doesn't really make sense to expose that on the Transform directly to me. It's a feature of GameObjects - what if you don't have a transform?
  • get_game_object_from_dont_destroy_on_load doesn't really make sense as a specific function, since we can already get the DDoL scene + game objects on arbitrary scenes
• Existing logic has some bugs
  • We have klass_name in the SceneManager offsets, but this doesn't really make sense there, since that's strictly to do with the version of Mono/IL2CPP
  • When traversing root game objects, it actually traverses in reverse

What?

• Split operations on a Scene into the Scene struct rather than being on SceneManager
  • root_game_objects, get_root_game_object
  • Removed get_game_object_from_dont_destroy_on_load (replacement is to get the DDoL scene then call get_root_game_object, like any other scene)
• Scene#root_game_objects now reads next instead of prev, so the objects are read in the correct order
• Add Transform#find_transform which traverses the game object tree for you via a path of game object names
• Split Transform into GameObject & Transform
  • Move Transform#get_name logic to GameObject#get_name, add Transform#get_game_object to Transform and make Transform#get_name use the above two
  • Move Transform#classes and Transform#get_class to GameObject
• Transform#get_class split into GameObject#get_class_mono and GameObject#get_class_il2cpp since the offset of klass.name depends on the mono version / il2cpp version, same way as it does in the regular path dereferencing code
• Add GameObject#is_active_in_hierarchy and GameObject#is_active_self, which are self-explanatory

Testing

TODO:

• Test on Mono versions
• Test on IL2CPP versions
  • since the offsets change here for class name especially.

[mitchell-merry]

"component" isn't accurate here, but there's something in between the component and the class. not exactly sure what it is.

[mitchell-merry]

we really need to implement some sort of strategy pattern here. The amount of code duplication is getting ridiculous

[mitchell-merry]

this changes depending on the mono version, which, of course it does.

Code updated to use the mono/il2cpp class name offsets

[mitchell-merry]

This makes more conceptual sense to live on the Scene rather than the SceneManager

[mitchell-merry]

no replacement for this - get the DDoL scene from SceneManager, then call get_root_game_object as with any other Scene

[mitchell-merry]

note: there's a change here, previously we were using [first, _, third] where first was our next element.

That's wrong: https://gist.github.com/just-ero/92457b51baf85bd1e5b8c87de8c9835e#file-list-hpp it actually causes us to go in the reverse order in the list. That caused me some issues in Cuphead

[mitchell-merry]

just realised this is already in #127, I'll take it out of this one when I get the chance