Fixed high CPU load due to constant rendering in the loop.

This PR fixes issue #25. The discussion of this issue points out that rendering has to occur in the three cases. It seems true, but just calling `renderer.render()` during dragging states by mouse reveals a worse performance than it was initially. It happens when a rendering rate, which depends on number of `mousemove` events, is higher then a possible animation frame rate. The solution is to use `requestAnimationFrame` and invoke it only when there is a need and the previous request is processed ('rendering_requested' attribute of the renderer).
And that has been done.

During resize of the window we can call `renderer.render()` directly for the immediate redraw. It looks better then calling `renderer.requestRender()`.

Below is the CPU load on my PC before this patch:
![before](https://cloud.githubusercontent.com/assets/2686981/5509468/b4156488-87b8-11e4-95dd-52f1b5658df1.png)

and after:
![after](https://cloud.githubusercontent.com/assets/2686981/5509478/caf19a5a-87b8-11e4-80d8-63c2e6e2df09.png)

On the last picture the high CPU load in the end occurs while dragging a state.
There was a type. Sorry for that. Thanks for your attention. Regarding rendering, I have to admit, it may be difficult to trace some bugs, since all the properties of automata (like acceptance, marking etc) can be changed with no methods, and each time you change it you have to update the view and render it.

I suspect that for undo\redo functionality you need to wrap all that with methods and use a command pattern. Then, it the rendering might be moved to these methods. But that's another story.