Rework how rendering works on the graphics thread

[bghgary]

Currently, the main rendering loop is a polling mechanism. The suggestion is to make this an event-based system and make it easier to use. Will fill in more details later.

Possible ramification:

• Calling Start/FinishRenderingCurrentFrame while nothing is being drawn can cause huge slowdowns in performance. For example, calculation bounding boxes without rendering with the current code will cause the CPU to spike because nothing is stopping the rendering from polling.
• If the JS side of things keep trying to add things to the native render queue without corresponding calls to StartRenderingCurrentFrame/FinishRenderingCurrentFrame, bgfx will run out of views the next time FinishRenderingCurrentFrame is called because all of the draw calls will be bunched up together. There is a related scenario where if the JS side is doing nothing (i.e., not rendering anything), then calling StartRenderingCurrentFrame/FinishRenderingCurrentFrame will also do nothing. If StartRenderingCurrentFrame/FinishRenderingCurrentFrame is being called in a tight loop, which it often is, then this will eat the CPU at 100%.

Also the JS side does not synchronously change bgfx state, it queues a bunch of commands into a buffer and that whole buffer is sent once per frame, and then all that state is applied on the native side to bgfx. This means the JS side could be working on the next frame (populating another command buffer) while the native side is processing the command buffer, setting bgfx state, rendering, etc.

We should also look at what is actually being queued from nativeEngine.ts. Some work may end up out-of-order if they are run immediately instead of queued.

Another problem is:

Setting a breakpoint in JS in Safari with Babylon Native will hang inside a NativeEngine::RequestAnimationFrame callback. It seems if the main thread in Babylon Native is blocked while stopped at a breakpoint in Safari web inspector, the web inspector will hang.