Throttle tiles to redo symbol placement at most once every 300ms.

[ChrisLoer]

Whenever the position of the camera changes (change in pitch or bearing), we have to run the symbol placement logic in GeometryTileWorker::attemptPlacement in order to do collision detection for the new geometry. Collision detection is too expensive to do on every frame, so we do it asynchronously on the worker threads, and update the render thread with new collision information whenever it becomes available.

The current implementation has the worker threads run placement requests as frequently as possible: the idea is that even though we can't do collision detection synchronously, we want it to be "as close as possible" to avoid the temporary appearance of collisions as the map rotates. This means that when the camera position is continuously changing (maybe in a "route following" animation), CPU on the worker threads will always be maxed-out.

This PR changes the behavior to throttle placement to at most once every 300ms. The benefits are:

• Less CPU usage on the worker threads -> less heat/battery impact, especially in navigation use cases
• Modest increase in the "stability" of label placement. It is possible for labels to show along a very short part of an animation path. The visual experience of seeing labels quickly appear and disappear is jarring and we'd like to avoid it if possible -- by running placement less frequently, we reduce the number of these "short lived" labels we're likely to show/hide.

The drawback of this change is that it widens the window of time in which labels can collide on the map before we detect and remove them. In the worst case (a collision that occurs the frame after the last time we re-did placement), it will add 300ms to collision detection time, and in the average case it will add 150ms. I don't think this is too big a problem because:

• 300ms just isn't that long perceptually, and if two labels momentarily overlap before one is removed, the effect is not that visually jarring.
• Our asynchronous approach already tolerates a fair amount of lag in collision detection.

In my testing of this PR running the macOS app in the debugger, I haven't been able to perceive a degradation in collision detection, while worker thread CPU use during rotation/tilting is dramatically lower.

Fixes issue #8435: while this PR doesn't change the mailbox message coalescing behavior, the throttling effectively prevents a backlog of onPlacement messages from piling up.

This change supports the pitch-scaling changes in issue #8967: with pitch-scaling, we have to re-do placement whenever we pan a pitched map, and this keeps the amount of CPU dedicated to re-placement under control.