Factor out update and draw calls into RenderingManager

[stanbsky]

Situation

We have two separate problems:

• different entities register in different managers, making it difficult to remove or get references from an entity in a different manager
• this also leads to tons of code duplication
• so much stuff requires a reference to the player, just to know where tf it is at a given moment inside its update loop

Opportunity

RenderingManager seems to be doing a bang up job of rendering and updating stuff, and it's static at that! Meaning we could easily bang out a static method letting you grab a player's position whenever needed. Also through the IRenderable interface, we can register anything that needs draw and update methods callling in one place.

Mission

Pull out as much stuff as possible out of the current ListOf... aka Manager classes. Where they have further functionality, we could maybe implement it as manager components, or via static access to the RenderingManager, or subclass the RenderingManager if not possible otherwise.

[stanbsky]

Planning

Consists of three types of lists: list of renderables (everything that needs update and draw), lists of objects that may need function calls (get position, health, etc), and lists of spawns (college, random)

• need two lists of spawns, one for colleges, one for pirates everything else
• need lists of colleges, pirates, powerups, quest objectives: these can index into the "list of renderables"
• list of renderables is drawn, updated, and checked for isAlive - if false, moved into list of things to dispose
• utility methods such as getRandomPirate, spawnBullet, collegesAlive, etc

Everything should be static if at all possible

[stanbsky]

Implemented in f950990b30740a8bd6c2e383a99260a6c06cb379

Further to the above, other changes were made:

• IDrawable now includes signatures for cleanup() and dispose()
• cleanup() (bad naming) returns true if the resource is ready to get removed from the game
• dispose() is called by the EntityManager before the resources are removed

Entity end-of-life cycle should look like this:

• entity is killed, sets isAlive to false
• if it doesn't leave a wreck (e.g. college), cleanup returns true
• dispose removes rigidbody, adds gold/score, records quest completion, etc.