AwakePriority virtual property

[microlith57]

this adds an AwakePriority virtual property on Entity, that can be used to change the order that Awake is called, similar to how Depth affects update and render.

• thanks to bit (micycle on codeberg) for the initial implementation!
• thanks to @cloudsbelow for suggesting the virtual property approach (chosen since it doesn't cost memory or performance per entity, while a component or field would)

testmod build: microlith57/CelesteTestMod#2 (check inside the workflow run)

[SilverDorian46]

while I don't believe in a feature necessarily having to supersede a different one, I'm just wondering...
what are your thoughts on the PostAwake event as implemented in #1055?
I'd also appreciate it if you'd review that PR as well - it's been left in the dark for quite a bit

[microlith57]

@SilverDorian46 i agree that this serves a very similar purpose to PostAwake, but i think they're different enough to peacefully coexist ^_^

[Wartori54]

I think having a whole set of 2^32 possible priorities won't be much more beneficial compared to doing two simple pre-awake and post-awake calls. I think that, in general, relying on people to assign numbers without any strict coordination will lead to many sporadic bugs when those priorities get changed: modder A uses the priority 0, modder B uses priority -1 to go before modder A, but then modder A needs to run before priority 0 because modder C has an entity that conflicts with modder A's entity, so modder A switches to priority -1 without ever knowing that modder B relies on modder A using priority 0; furthermore, modder A may set priority to -10 to ensure it always runs before modder C, breaking even more entities that may lie between priority -10 to -1.
And while having pre-awake, awake and post-awake wont really fix that issue, at least it prevents races between modders to assign an even lower and lower priority, and instead encourages modders to coordinate how their entities work and interact.
Finally, doing pre-awake and post-awake allows us to not need to worry about having to sort the toAwake list, only occupies two extra slots in the vtable of every entity subtype, and allows entities to have what would effectively be multiple priorities with the proposed implementation in this PR (doing stuff in pre and post awake).