high-DPI support

Nobody has claimed this yet.

TileJSON should have a means of:
- indicating when a source supports high-DPI versions of base tiles, and at what DPI multipliers (`@2x`, `@4x`, etc)
- specifying how URLs for high-DPI tiles are constructed

Without such a specification, consumers must have hard-coded knowledge of a source's support for high-DPI tiles and typically [resort to string munging](https://github.com/mapbox/mapbox-gl-js/pull/959) to generate the appropriate URLs. These are exactly the sort of deficiencies that TileJSON is designed to eliminate.

One approach would be to have an array-valued property that lists supported DPI multipliers and a new interpolation key for tile URL templates. E.g.:

```
{
...
"dpis": [1, 2, 4],
"tiles": ["http://example.com/{z}/{x}/{y}{r}.png"]
}
```

Where it is specified that `{r}` is replaced with the pixel ratio ⇢ string mapping of 1 ⇢ "", 2 ⇢ "@2x", 4 ⇢ "@4x", and consumers may decide which of the pixel ratio options to use based on device characteristics. Alternatively this mapping could be explicitly supplied:

```
{
...
"dpis": {
"1": "",
"2": "@2x",
"4": "@4x"
},
"tiles": ["http://example.com/{z}/{x}/{y}{r}.png"]
}
```

These approaches introduce a backward compatibility issue however, in that existing TileJSON consumers will not be prepared to interpolate a new template value and thus cannot consume TileJSON that uses it.

cc @yhahn @mourner @tmcw

Review the existing TileJSON specification and the issue's proposed `dpis` and `{r}` additions, then examine how backward compatibility for existing consumers should be handled. Done means an agreed high-DPI representation and URL-template behavior are documented without leaving the compatibility question unresolved.

Written by the indexing model from the issue text.