centralize types

[jakebball]

I believe it would be beneficial to have all the commonly used types in a single types module. The first obvious adavantage is that it can easily change the types. The more important reason for this would be the ability to grab and use the types within your own code. Right now there are two options to do so, first one is to create your own types which is cumbersome for something that Stitch should have the responsbilitiy of having and exporting. The second option is to dig through all the World's sub modules which is very cumbersome as well and goes against Stitch's design of most functionality coming from the World API. I believe the best way to solve this (which is what I did in the commit) is to simply have a single types module which exports all the types allowing the user to have easier access to the Stitch types while also having the ability to stay away from the internal submodules of the World object (expect for the Types module itself of course). To solve the circular dependency of World requiring the types module but the types module also needing the World object for the world type I return a set function inside the Types module which is used at the start of the world to set the world object accordingly without the need for Types to require the parent World class. I acknowledge this solution isnt as clean as I like it to be but it is the best one I can think of so far.

UPDATE:

The setWorld api and wonky behavior has been removed by having a world interface beneath the Types module instead.