Draft: [Capabilities] Implement capability registration

[RedBrumbler]

• [x] Adds Capability registration and deregistration
• [x] Lets consumers of the API check whether a capability is registered
• [x] Lets consumers of the API register to an event that gets triggered when a capability is removed or added
• [x] Tells the consumer of the API whether that capability was removed or added

[RedBrumbler]

Before merging, we need to have a think about these things:

• Should we add guarding for multithreaded accesses? or should we enforce single-thread accesses?
• Should the event be cleared upon game restarts, or is it up to people who subscribe to it to unsubscribe properly?
• In the case that we make it not reset, why even have things behind the instance? everything would be static... it'd make more sense to then just store and implement everything static and just provide a zenject layer to access these things through an instance that way

[raineaeternal]

1) For simplistic use, I would guard against multithreaded access (std::mutex?) 2) Make people unsubscribe properly, but log out whoever is still subscribed and call them the fuck out. 3) The instance is required for non-Zenject access. How it's done past that, I don't mind.

[RedBrumbler]

1. ic, ok
2. there is no way to tie a callback back to who registered it I believe, but I could check whether the func ptr is traceable
3. it currently is, but it doesn't have to be... due to the way this works it means someone who's not zenjecting has to artificially delay registering capabilities because they can't do it in late_load() because zenject hasn't ran at that point

[raineaeternal]

ok, I see. If there is a better way of doing instancing/zenject access, feel free to explore that possibility. So long the API is clean and simple to follow, I don't really care too much.

[RedBrumbler]

• [x] Rework ordering to make zenject api just redirect to static api
• [x] Implement mutexes to guard against multithreading
• [x] Yell at people who don't unsub themselves from the zenject event not possible, eventcallbacks don't provide access to the registered function pointers