[ios] Support getLeaves (and related) clustering methods

[julianrex]

Fixes #12442.

This WIP PR adds an MGLPointCluster protocol, and - (id<MGLPointCluster>)cluster to MGLPointFeature which returns non-null for clusters. (MGLPointFeature conforms to MGLPointCluster privately).

We could also consider these options:

• Add the above cluster method to MGLFeature, for future compatibility (e.g. if supercluster supported features other than points)
• Instead of a protocol, create a subclass MGLPointFeature for point clusters, e.g. MGLPointClusterFeature. This may be preferable, but again if other features end up being clustered we could suffer an explosion of types.

Still TBD: documentation, tests, macos project.

This PR introduces a new public protocol, MGLCluster, that private types (that conform to MGLFeature) will also conform to if they have the appropriate cluster attributes. MGLPointFeatureCluster (a new subclass of MGLPointFeature) conforms to.

(Currently the only supported type that adopts MGLCluster is a subclass of MGLPointFeature.)

This also adds:

• -[MGLShapeSource leavesOfCluster:offset:limit:]
• -[MGLShapeSource childrenOfCluster:]
• -[MGLShapeSource zoomLevelForExpandingCluster:]

exposing features added to supercluster
/cc @tobrun

[captainbarbosa]

Happy to review more docs as you write them.

[captainbarbosa]

When you do write the docs for this part, I think its a good idea to add extra clarification on what are leaves vs. clusters since the metaphor is a bit odd.

[1ec5]

Really curious to what extent we can align with MapKit’s built-in clustering API. Certainly there are structural differences in the underlying data and types that we have to work with, but it would be helpful to be able to say that such-and-such clustering-related type in MapKit is analogous to such-and-such type in this SDK.

[julianrex]

@1ec5 I think that's a great goal - I'm hoping that a simpler interface along the lines of MapKit's can be something that can follow after and inform this PR. /cc @chloekraw

[1ec5]

Reading the MapKit documentation more closely, I think there may be opportunities to align terminology but not the API itself, because MapKit’s clustering feature is rather application-driven, whereas the application passively consumes the contents of the style in the API being presented here. We’ll have more opportunities to align API members when we get around to implementing #5814 and especially #5815.

[julianrex]

@tobrun I've updated this PR with latest changes - would you mind checking to see if this matches what you expect?

[tobrun]

LGTM

[friedbunny]

Two small notes.

[julianrex]

This PR is now the equivalent of the Android PR (#13631) due to the introduction of the queryFeatureExtension API introduced in #13382.

Because of the introduction of this API, this PR has been refactored so that an MGLShape that conforms to MGLCluster is used: specifically this is MGLPointFeatureCluster (a subclass of MGLPointFeature). MGLCluster has not changed other than the static free functions that were used to create cluster subclasses at runtime being turned in to methods of MGLPointFeatureCluster.

If it turns out that types other than MGLPointFeature can be clustered, we can revisit. Though I suspect that we'll want to address #7454 before then.

[friedbunny]

Tiny nits and a couple small documentation suggestions.

[friedbunny]

☝️