Refactor handlers to use a requestRenderFrame callback rather than Camera#_startAnimation

[anandthakker]

#6005 introduced Camera#_startAnimation as a hook to allow interaction handlers to perform map updates on a schedule controlled by the render loop (rather than having their updates be interleaved with render frames). This approach is problematic because it assumes that only a single interaction handler or programmatic animation "owns" the camera for the duration of any given render frame. As @jfirebaugh points out, this makes handler behavior sensitive to event timing:

For instance, if you receive both drag and scroll events within a single render tick, or receive mousedown, mousemove, and mouseup within a single render tick, things go awry

A better design would be to expose Map#_requestRenderFrame(cb), allowing handlers or animations to register a callback to be called during the next render frame. In addition to fixing the issues described above, this would allow the camera and handler code to be written just like it would be if we were using requestAnimationFrame(), which will make it clearer and more readable.