Add methods for inspecting GeoJSON clusters

[mourner]

Closes #3318. Introduces 3 new methods to clustered GeoJSON sources:

• getChildren for returning cluster's immediate children (from the next zoom)
• getLeaves for returning original points that belong to the given cluster, with pagination support.
• getClusterExpansionZoom for returning the zoom the cluster expands on.

map.on('click', 'cluster', (e) => {
  var clusterId = e.features[0].properties.cluster_id;

  map.getSource('geojson').getClusterExpansionZoom(clusterId, (err, zoom) => {
    ...
  });
});

Misc. open questions:

• Is it worth adding unit tests for this, and if so, how? The methods are just a thin layer between the GL JS API and the Supercluster library, and the functionality is tested there directly. We could add tests similar to those for GeoJSONSource#setData, but they don't actually test the roundtrip — they just mock the dispatcher send method, so for this case I doubt such tests will be useful.
• Is the minimal flow typing in geojson_source_worker enough, or should we try doing something elaborate (e.g. setting up Supercluster/GeoJSON-VT typings, casting the index to either etc.)? Currently GeoJSONIndex interface in the master branch is empty and typing checks for it don't run at all for some reason — e.g. there's this._geoJSONIndex.getTile(...), this method isn't typed anywhere but Flow doesn't complain.
• Is it worth packing the features through vt-pbf when sending them back? In most use cases, the payload will be tiny (a few point features), so getting maximum performance didn't seem necessary here, so for now I'm just sending GeoJSON directly. Should we leave it like this and get a round of feedback before trying to optimize?

Launch Checklist

• briefly describe the changes in this PR
• write tests for all new functionality
• document any changes to public APIs
• n/a post benchmark scores
• manually test the debug page

[jfirebaugh]

I think it's fine with manual test page and without vt-pbf packing for now, but the flow types could be more precise -- see inline comments.

[jfirebaugh]

Type the callbacks more precisely, e.g. Callback<number>.

[jfirebaugh]

Callback<Array<GeoJSONFeature>>

[jfirebaugh]

We're using the Array<GeoJSON> convention rather than GeoJSON[].

[jfirebaugh]

Let's replace export type GeoJSON = Object above with types from flow-typed/geojson.js.

[lewis500]

Is there any good way to find the cluster_id associated with a given piece of data?

I have a map with clusters on it. When people search for something and select it, I want to highlight which cluster it's a part of.

[andrewharvey]

Is there any good way to find the cluster_id associated with a given piece of data?
I have a map with clusters on it. When people search for something and select it, I want to highlight which cluster it's a part of.

@lewis500 I guess you could use map.querySourceFeatures to get all the cluster_id's of visible clusters, then do getClusterLeaves on each to build an index of features => cluster_id's. Certainly not ideal and only works for clusters in the view, otherwise you'll probably need to use private undocumented methods and properties.