Rework core engine

[aggregate1166877]

Details:

Intro

Main task: Create a formal plugin mechanism, and migrate existing code into
that mechanism.

Going forward, use ChangeTracker instances for important vars. We should also
make a habit of making "global" vars uniquely named for mass refactoring
purposes.

New model

First off, no more per-module vars. In this particular project it doesn't work
for most cases, and refactoring it is hell. Everything should be a class or
prototype, no exceptions.

Everything should be a plugin unless infeasible (or complete overkill). For
example, the spaceship loading mechanism hooks into the core mechanism. Ship
modules hook into each spaceship. Plugins should be live loadable. This allows
any new spaceship to load seamlessly, and allows ship modules to be swapped out
on a whim. Another point of interest is the universe system: we should be able
to activate shaders such as god-rays based on certain triggers managed via
ChangeTracker, such as "new local star loaded" (which the shader manager can
then track based on cachedValue).

The way the plugins will work is with dependencies. At boot time,
all plugins specify what they're targeting. The shader manager registers itself
as tracked.shaderManager, and targets tracked.spaceScene. Meanwhile, the ship
loader registers itself as tracked.playerShip. Don't be fooled into thinking
the playerShip needs to track the universe - all it does is report engine
output and the like. It's up to other modules (such as the shader manager) to
determine how space information works. It should shine if the camera is close.
This has nothing to do with the player ship.

When using ChangeTracker instances, don't confuse initialisation with updating.
If we notify a spaceship change, it means we've loaded a whole new ship. It
does NOT mean we changed the ship's colour, for example. Similarly, we shouldn't
notify coordinate changes every frame. Notifying that spaceScene has changed
indicates that we've replaced the entire universe with a whole new instance.

In terms of important items that need to be presented as arrays, consider
making appropriate manager classes. For example, if we spawn in multiple
AI-controlled ships, we need to manage them. We can do this with a generic
group manager, or with an AI class specifically designed to care about each
ship. We certain can wrap them in ChangeTrackers, but if the AI can manage them
just fine by itself, then we may instead need trackers for things like "an
enemy locked on to you [pass instance]".

Levers, switches, and the like, should be part of a interactables managers. The
interactables manager loads level items and triggers trackers (such as "an
interactable is near").

TL;DR: nothing should use global vars. Everything is a class, and any class
that is extensible has a tracker. Main trackers only triggers when their
wrapped children are (re-)instantiated, but trackers inside children are
allowed to trigger for general events. Boot events may be presented as
trackers.

ChangeTracker type disambiguation

One problem (and nice feature) about the ChangeTracker is that it's very generic. We can use it to track variable initialisation, but we can also use it for pub-/sub-like event management. We also really need to know if we are, for example, looking at a scene or a scene managed by a ChangeTracker instance. I'm not a fan of type-hint prefixing in variable names, but I think it's required here to make it clear what we're dealing with in all cases.
Proposal:

• Tracked instances are prefixed tr.
• Pub-/Sub-like instances are prefixed ev.
• Handler-like instances are prefixed on.