Modularization

Nobody has claimed this yet.

`kami` is currently pretty big for NPM standards. I'm considering splitting `kami` into a number of smaller modules.

`kami` will export three core modules:
- WebGLContext
- ShaderProgram
- VBO / IBO

The rest would be split like so:
- `kami-fbo` FrameBuffer
- `kami-basebatch` BaseBatch
- `kami-spritebatch` SpriteBatch
- `kami-mesh` Mesh (wraps VBO/IBO)
- `kami-renderer` ImmediateModeRenderer
- `kami-texture` Texture
- `uv-region` TextureRegion (not kami specific)

This is a major breaking change, and demos will need to change to reflect the new structure.

Some downsides:
- Worse module discover. There is going to be a proliferation of kami modules
- Scattered documentation
- Folder fragmentation which makes development a bit more difficult and error-prone
##

Another solution would be to re-think some of the classes to make them truly modular, i.e. not depending on any other aspect of kami. The main difficulty with this is maintaining WebGL context loss.

Start by reviewing the current kami package structure and how the demos import its classes. Compare the proposed core modules and separate packages, including the WebGL context-loss concern, before choosing an approach. Done means the modular package structure is implemented and the demos reflect the new module boundaries.

Written by the indexing model from the issue text.