Multiple bounding boxes for tile layers

Nobody has claimed this yet.

## Motivation

I've come across a lot of different tile layer sources over the years which tend to have multiple areas of coverage (multiple bounding boxes). A great example of this would be a high resolution imagery layer that only focuses on urban areas. Currently to limit the tile requests to these areas we have to create a layer number of tile layers, one for each bounding box.

## Design

It would be great if we could specify multiple bounding boxes in a single layer, or possibly a MultiPolygon instead. Not sure of how else to handle this. One potential issue with this approach is that processing time of determining if a tile is within the coverage area or not. To improve performance this could be pre-calculated when the tile layer is initially loaded and an index created based on the tile ids. Limiting this to bounding boxes, would simplify things and may be good enough for most scenarios like this.

### Mock-Up

For a developer, they would simply pass in an array of bounding boxes as an alternative to passing in one.

### Concepts

This isn't much of a change from the API interface point of view, so not much to new learning required. This would also be beneficial to those who use OGC services that have complex coverage areas.

No implementation files or tests are named. Start by reviewing the current TileJSON bounding-box representation, then resolve whether arrays of boxes or a MultiPolygon should be supported; done means one layer can describe multiple coverage areas in the specification.

Written by the indexing model from the issue text.