[iOS][WIP] Improve annotationsView performances

[naluhh]

This PR adresses the following issue:

• MGLMapView calls MGLMapViewDelegate 'viewForAnnotation:' for annotations outside visible area #6173

What changed ?

updateAnnotationViews was not working properly. The delegate method was called on each frame even if it wasn't in the view work. As a result, performance were worse when an annotation was outside the screen (!).
The reuse queue was also an NSArray instead of a NSSet resulting in poor performance when picking inside.

This PR improve the performance of the updateAnnotationViews especially when you are using complicated views.

One possible improvement to this would be to use queryPointAnnotations, but it's too slow when there is a lot of annotations on the screen.

Testing done

I tested with thousand views and CAAnimation spread across the world with much better performances.

cc @1ec5

[mention-bot]

@naluhh, thanks for your PR! By analyzing the history of the files in this pull request, we identified @boundsj, @1ec5 and @friedbunny to be potential reviewers.

[boundsj]

Thanks for the contribution @naluhh! I will review as part of #5987 that I'm currently working on again now that #6055 is fixed.

[boundsj]

Thanks again for your PR @naluhh. I went with the implementation in #5987 because we wanted a solution that relies on the more efficient query mechanism in the mbgl (C++) core. Also, I wanted to stay away from implementations that rely on changing the visibility of the UIView objects. I was also concerned about using a set for the queue since we would not want to store only distinct views based on a hash -- we want to be able to reuse any view that has been created previously.

I understand this PR also introduced a new public API on MGLAnnotationView called willBeEnqueued. I'm not sure I see the value of that compared to the existing prepareForReuse API that is also more familiar to users that have experience with similar APIs (like MapKit's and UITableView). It may also leak more than necessary about the underlying reuse mechanism. Please do feel free to submit another PR with the changes for willBeEnqueued if you feel you can make the case for it.

Thanks again!