Fold MGLTileSet into MGLRasterSource and MGLVectorSource

[1ec5]

MGLRasterSource and MGLVectorSource should have a new abstract superclass, MGLTileSource. MGLTileSet should be removed and its initializers and properties moved to MGLTileSource. (We could perhaps rename MGLRasterSource and MGLVectorSource to MGLRasterTileSource and MGLVectorTileSource; I don’t have a strong opinion on that.)

Per #6584 (comment), the days of a formal “tile set” API are numbered. As it is, the fact that MGLRasterSource and MGLVectorSource use MGLTileSet as a value class for their metadata makes it impossible to elegantly roundtrip source properties (#6584). A case in point is the MGLTileSet.attribution property: it should be possible to get a source’s attribution string, because mbgl::style::Source has a getAttribution() method. But note how it lives on mbgl::style::Source rather than mbgl::style::TileSet: in order for MGLTileSet.attribution to return the attribution string of a source defined in the style, our only two options are:

• To have MGLTileSet maintain a backpointer to MGLSource, which prevents MGLTileSet from being used as a value class; that is, no two MGLSources can share the same MGLTileSet.
• To have MGLRasterSource.tileSet and MGLVectorSource.tileSet synthesize a dummy MGLTileSet that contains just the attribution string but no other information like URL templates.

Both these options are inelegant, so we should instead follow the lead of mbgl and make its initializers and properties part of every MGLRasterSource and MGLVectorSource instance. Putting them in an MGLTileSource superclass avoids proliferating initializers and duplicating documentation.

There are parallels to the hierarchy of abstract classes under MGLStyleLayer (see MGLForegroundStyleLayer and MGLVectorStyleLayer). If there’s a strong possibility that we might want to organize the concrete source classes under a criteria other than tiling, for example by vector versus raster models, we could have MGLRasterSource and MGLVectorSource share a protocol instead, but I think I like an abstract superclass more than a protocol for this purpose, given that designated initializers are involved.

/ref #5999
/cc @mapbox/ios @ericrwolfe @jfirebaugh

[1ec5]

Now all the options for an MGLTileSource need to be declared upfront on initialization, whereas you could initialize an MGLTileSet and continue to modify it as much as you want until using it to initialize an MGLRasterSource or MGLVectorSource. So I think I’ll have the initializer accept an option dictionary and have read-only accessors for the properties we can actually get out of an existing source.

[1ec5]

This is happening in #7377.

[1ec5]

Fixed in #7377 on the iOS SDK v3.4.0 release branch.