- Fleshed out props a bit more. Edited sprites to keep track of their current position/size in the spritesheet and the image they reference.
- Updated test loop to reflect the changes.
- Render methods now take a prop as an argument

The result of these changes is that the prop can contain everything the renderer needs to know to draw that prop.

We also got a massive performance boost, though I'm not sure what I changed that caused it. Might have something to do with moving
the requestAnimationFrame call to the beginning of the update call, instead of the end. Anyways, down from 25% CPU (100% of a thread)
to about 5% CPU, which also means it's rendering consistently at 62 fps.
Fixed this not working in the requestAnimationFrame calls.

Made shims a module. Will probably split it into multiple shims when needed.

Experimented with buffering through a shadow canvas, but that slowed things way down.

Added tick, to allow for animations to run at timings other than once per requestAnimationFrame loop.
Moved tick to the main engine where it belongs.
Fixed derped parentheses
Added loop and tick to engine. You now create the game loop by calling lithium.init()
with a callback function you wish to run on every game loop iteration
and the target fps you wish to run your game at. Note that currently, fps is restricted by rAF,
so you can't target larger than 60fps. This is purely to limit your game to something lower than
rAF would.

Might want to switch the engine loop to using a timing mechanism, instead of relying on setTimeout.
Also, we may want to separate the animation loop and the logic, which would require a second loop.

More research is needed.