Librarization of engine code

[no-lex]

Cutting off and providing a hard interface between game-inspecific engine code and game-specific code helps resolve several issues that are otherwise structurally hard to solve:

• Provides an engine interface which can be limited, and therefore, well documented
• Allows for the creation of dummy test games which can provide regression testing
• Allows for the project to provide a widely useful base which can promote other projects using it (increasing the # of eyes on the engine source code)
• Allows for the project to clearly delineate between game and engine code and avoid messy dirtballing of cris-crossing function dependencies
• Allows showcasing and marketing the engine as a standalone solution rather than an already heavily integrated part of a game

Doing this requires the following:

• [x] Converting iengine.h into an exterior-only header (the header that a prospective game would include)
• [x] Dissolving igame.h by moving the engine scope to only have the game call engine functions (and not have the engine call game functions)
• [x] Moving main.cpp into the hands of the game maker, making the engine have no process of its own
• [x] Compiling the engine code not as a program but a static (maybe later, dynamic) library.
• [ ] Declaring export functions and other symbols for Windows DLL compilation.
• [ ] Documenting the API that the game developer would need to understand to create a game with the new library.