[core, darwin, android] Add onDidBecomeIdle to MapObserver.

[ChrisLoer]

'didEnterIdle' fires whenever render completes and no repaint is scheduled.
Fixes issue #13469

Potential issues:

• This logic doesn't know anything about animations that are being driven by the SDK instead of through the core transition logic. In practice I think this probably won't be a huge issue because if the SDK is running an animation, it will keep triggering placement, which will keep the renderer from entering idle.
• Potentially confusing to add an extra event, since we've already got "didFinishRendering/fullyRendered" and "didFinishLoadingMap". However, I think the name "idle" is a pretty good description of this event, and matches up better with what users have expected to get from the other events.

cc @tobrun @julianrex @ansis

[tobrun]

@ChrisLoer
did a quick test with Android SDK animators and idle is only fired at the end of the animation 🚀

[1ec5]

In practice I think this probably won't be a huge issue because if the SDK is running an animation, it will keep triggering placement, which will keep the renderer from entering idle.

On iOS, CADisplayLink continually rerenders the map 60 or 120 times per second by default, irrespective of whether any re-placement is necessary. Does that mean the renderer will never idle on iOS?

[1ec5]

Potentially confusing to add an extra event, since we've already got "didFinishRendering/fullyRendered" and "didFinishLoadingMap". However, I think the name "idle" is a pretty good description of this event, and matches up better with what users have expected to get from the other events.

Note that our implementation of -[MGLMapViewDelegate mapViewDidFinishRenderingMap:fullyRendered:] is incomplete precisely because it doesn’t get called when errors have prevented one or more tiles from loading: #1804. But that method doesn’t relate to animations anyways, just style and tile loading.

[ChrisLoer]

Does that mean the renderer will never idle on iOS?

No, the mbgl core rendering itself idles. If it didn't, we'd be wasting a lot of energy!

One related thing I noticed in manual testing, however, is that when you touch the screen to begin an interaction, the first touch will trigger a paint before there's actually any movement (which would trigger placement/animation/etc.). So if you drag the screen to pan somewhere, you see two idle events -- the first when you initially touch the screen, and the second when the pan is done and all animations have finished. This is right from the point of view of the renderer, but may be surprising to someone listening to the idle event.

[ChrisLoer]

@1ec5 @tobrun I think this is ready for another round of review.

[julianrex]

Thanks for adding this! LGTM