Synchronous rendering

@ibawt @kristianpd @nickjs 

This removes the bits in `Renderer` which popped the stack every x milliseconds in favour of just going until the render is done, and then fixes the issues that cropped up because of that. Truth be told the code changes to `Renderer` are pretty small, and the other stuff was just bad tests that relied on the `setImmediate` for render starting and a couple bindings which accidentally implicitly relied on that as well.

So, things got faster! See the loop rendering benchmarks, where the light blue is the new code and the dark blue is master:

![screen shot 2013-05-09 at 3 33 44 pm](https://f.cloud.github.com/assets/158950/484796/63f3b7e4-b8e2-11e2-9753-9a4d936015a7.png)
![screen shot 2013-05-09 at 3 33 25 pm](https://f.cloud.github.com/assets/158950/484797/63fbeaa4-b8e2-11e2-87f8-c3745b5b8211.png)
![screen shot 2013-05-09 at 3 33 35 pm](https://f.cloud.github.com/assets/158950/484798/63fd89cc-b8e2-11e2-869f-3d03dc31b37d.png)

Pretty big improvement, but its not without its caveats. One, the whole reason we did the stack pop in the first place was to allow the browser to scroll and do other user-responsive stuff while the page was rendering. This will undo that and soak up all the CPU it can until the render is done, so we should do some testing in old browsers before merging/vendoring. Second, no API changes have really been made (except for the removal of the implicit setImmediate in the `Renderer` constructor) which I was actually hoping for. I think, and please tell me if I am wrong, that rendering will always be truely "asynchronous", since we might have to do network stuff to go get the view, or a partial, or what have you. Any binding can prevent the `rendered` event (and later allow it) on the parent `renderer`, so the lowest common denominator API the `Renderer` must support is evented and asynchronous. Darn, I was hoping for some simplification.

So, other concerns with this? Shippy shippy fasty fasty?