Font fallbacks (css-esque)

Nobody has claimed this yet.

## Motivation

The failure state of font loading is confusing and frustrating. Fonts are loaded based on tiles, and when a font fails to load (e.g. with a 404, common if a font is erroneously deleted or a style is shared to another Mapbox account) the map fails to render. Fine at one zoom level or map location, broken once a user navigates to a problematic spot. It's a problem that can hide until a map is published, receiving production traffic.

## Design Alternatives

We could interpret the text-font property as a font load stack as well as a glyph range stack. Currently, if my layer's `text-font` property looks like this `text-font: ["brandon grotesque", "impact", "open sans"]`, we will attempt to pull glyphs from `impact` if there are glyphs that aren't covered by `brandon grotesque`, and then finally we would fall back to glyphs from `open sans` if there are glyphs not covered by `impact`. We could also treat this as a font load stack, loading glyphs from `impact` if we fail to load `brandon grotesque`, and loading `open sans` if we fail to load `impact`. This change in how we interpret the spec may align better with existing user expectations since this is how font stacks work in CSS.

We could also serve a baseline font at the API level as a "last line of defense" but personally I'd prefer to go with the above option, and leave this firmly in implementors' hands.

Start by tracing the implementation of the `text-font` property and the font-loading behavior described in the issue. Compare the current glyph-range fallback with the proposed CSS-like font-load fallback, and define completion as preserving map rendering when a listed font fails to load.

Written by the indexing model from the issue text.