Wow this is a big one.  If I weren't already behind I'd split this commit into separate parts.

Experimented a lot on how to best handle looking up items.  That turned into an overhaul of most of the existing types, which have now been moved into a separate script.  Again, can be inlined for release, just separated them out for the sake of maintenance.

Implemented base constructor GameObject, which represents anything that exists in the game.  I would have called this an actor as I'm used to that from Unreal Engine 4, but with actions and commands and such, I'm worried it would be confusing to have actors as well.

GameObjects have ids, names, and descriptions, as well as an onLook() function.  They are constructed by various helper functions in adventure.game.  This moves us nearly to completing issue #6, and the basic event support moves us partway toward #26.

Rooms are GameObjects that the player can occupy.  They also hold inventories and have additional properties and events.

Added a directions object that holds all the possible values, NESW + up/down + in/out.  It also has a helper function to find the opposite of a given direction.  Added two functions to game, registerConnection and registerTwoWayConnection, which consume direction values and room ids to handle room connections.  Closes #9

Removed all traces of output variables, that was a bad idea that got worse when I started using strings and arrays as outputs in different sections of the code.  Now there are only calls to adventure.console.print.  I should have a wrapper in game though, so I can associate all of the printed lines with the command that triggered them.  Closes #29

Console defaults to "> " as a prefix rather than "".

Cleaned up game.onStart(), which now appears to be just a call to setCurrentRoom().  Keeping it around because I'd like to do some things on starting an adventure, but if it goes unused much longer it should get the axe.

Defined a hard split on the game API.  It is now not allowed to return GameObjects, only identifiers for game objects.  Will mean more convenience functions, but that's a small price to pay for the ability to reason about game state a little easier.  Closes #21, the answer is yes we should.

LOOK and GO delegate most of their work to game now, as a requisite of no longer allowing GameObjects out of game.

Cleaned up the default adventure significantly, and added another location.  This was needed now that game is the only thing that can edit GameObjects.