Adds FPS limit option to preserve browser performance

[userexec]

Adds fps to options and associated documentation. Works by calling a setTimeout at the end of each draw instead of immediately calling the next draw. setTimeout is controlled by fps option, or can be set to 0 for no throttling. Defaults to 60FPS, which should keep Firefox tabs from crashing when they encounter this library.

Draw loop tracks elapsed time since last draw and multiplies particle speed by time so that the distance particles cover stays the same regardless of the chosen FPS. Speed is also divided by an arbitrary number to keep the distance covered by certain clock speeds roughly equal in the frame-limited animation loop to what they would have been in the unlimited loop. This is just so a clock of "25" still looks the same speed as it did without frame limiting.

fixes #23

[davwheat]

Personally, I'd be more in favour with calling requestAnimationFrame on every screen refresh, like normal, but then using logic within the animation frame handler to control skipping a new render.

https://stackoverflow.com/a/19772220/11091039

[userexec]

That does seem like the more technically correct way to do it. I'd be curious to see if Firefox handles it well or just chokes from handing over too many resources to unlimited repeating calls. The settimeout solution was definitely an axe vs. scalpel situation where we just wanted Firefox to chill out and take a break.