Refactoring ECL patching and stage warps meta thread

[32th-System]

The core of what thprac does for it's most central functionality. Doing anything to it should be backed by some discussion.

Some discussion has already happened here: #92

What do I want the system to look like?

The way I'd like to think of stage warps is by thinking of the stage as a linear timeline, with all stage sections, the midboss(es) and the boss being points on this timeline. Things like individual midboss and boss attacks (both nonspells and spells) should be considered subphases of the boss, with the idea of a "boss" or "midboss" technically not even being a part of how the system works

Basically, the way it works in TH185 should be kinda how I want it to work in all games. In that game, there's structs that describe how stage warps look, with the code that applies stage warps just looping through the structs.

The problem with how it's done in TH185 right now though is that those structs are not constinit. Basically, information about stage warps is data known at compile time. It should therefore be laid out in thprac's static memory in a way where the code responsible for applying stage warps can work with that data directly. There should be no need for things like static constructors that copy data from static memory into heap allocated buffers before it can actually be used by something.

In fact, fixing this is what motivated the rewrite of the hooks system. I certainly don't want to introduce anything new where all data is known at compile time but which isn't constinit.

To summarize: stage warps should be described by structs that form a tree-like structure, and it should be possible to initialize those structs as constinit, but it should also be possible to generate them at runtime.

I have some structs here: https://godbolt.org/z/GzMGzv9n3 but I'm still refining this

What does it look like right now?

In TH185 there's definitions for structs that describe stage warps with there being functions that apply those warps from those structs and the stage warps are specified by creating instances of those structs. The structs are not constinit, I've already described why I don't like that.

In other games, there's unique constants associated with every position in a stage that you could possibly want to warp to. These warps are then applied by calling a function that puts the number it gets into a giant switch case, and based on what case it lands on, it then just writes data. There are no struct definitions, the code in the switch case just writes the data directly.

This is of course not very good for mod support.

Another part of how this system works is that all stages are assumed to follow a strict structure: Stage sections, midboss(es), boss. If something doesn't fit into this strict structure, there's a workaround to make it fit into that structure. For example, being able to warp to any stage section used to not be a thing. There were however still notoriously stage stage sections that players still wanted to practice (example: TH06 stage 4 books). To remedy this, Ack designated those stage sections as midboss nonspells.

How should replay support work?

In the current system, the constant that corresponds to the correct stage section is written into the replay file. I think I just want to store the ECL modifications themselves in there.