Switched list iteration flow for GameObject rendering and updates

[huggyex64]

Instead of iterating over all the active objects to gather the renderables, call updates, call fixedupdates, etc..., this implementation has the objects subscribed to an event manager that reduces the call overhead by a lot.
Among other notable improvements, there are:

• guaranteed execution order
• smaller memory footprint
• overall performance benefits

Following are two small benchmarks ran with ~1800 gameobjects with 7 monobehaviour each, for a total of ~12600 monobehaviours. each with an Update that rotates the transform.
before:

after:

[michaelsakharov]

First off, thanks for taking the time to put this together

Ive gone through the PR, and I think the performance improvements are significant
The core idea of moving away from iterating over every GameObject each frame is absolutely in the direction I want the engine to go

That said, Im not convinced we need the full event framework to achieve it

If the main issue were trying to solve is avoiding full GameObject traversal every frame, I think the solution may be able to stay much simpler

For example, we could potentially maintain static collections of active components that participate in Update, FixedUpdate, rendering, etc, with components registering and unregistering themselves as they become active or inactive, based on whether those virtual methods have been overridden which could be cached per type

That would give us many of the same benefits:

1. No full hierarchy scan each frame
2. Only iterate components that actually participate (though less precise using a single collection, if needed we could do one collection per method)
3. Minimal memory overhead
4. Very little code (if the static lists go on MonoBehaviour or somewhere else we can avoid an additional supporting class)
5. Easy to reason about and debug

The event system certainly works (in fact I think its quite clever could be a nice standalone Prowl library) but I also feel it pushes Prowl away from the KISS philosophy the project is built around
It introduces significantly more infrastructure than I think the engine needs for this particular problem

Would you be interested in exploring a simpler implementation focused specifically on update/render registration?
I'd love to hear your thoughts on that as well as any other paths/solutions you might have

Either way, I really appreciate the work that went into this PR
It helps validate that moving away from GameObject iteration is the right direction, and the performance gains here are valuable data for whatever final implementation we land on

[PaperPrototype]

My suggestion for this PR is: make it do the LEAST amount possible needed for GameObject components to subscribe to events, and thats it. This PR looks like an entire Event system package. As an example of what Wulferis means by "KISS" (Keep it simple stupid) the EditorAssetDatabase is at most 5 scripts in total.