Automatically add default blend/base style pairs

[bcamper]

This PR attempts to ease another common pain point with blend modes, as a follow-up to enabling blend_order to be set at the draw level in #703.

In this case, the goal is to make it easier to use the different blend modes without having to write boilerplate styles. However, this PR takes a different approach than was used for blend_order. For each combination of blend mode (opaque, overlay, etc.) and style base (polygons, lines, etc.), a style is automatically created at scene load-time with the naming scheme blend_base, e.g. translucent_polygons, overlay_lines, etc. Each of these is a minimal style definition, such as (if expressed in YAML):

translucent_polygons:
  base: polygons
  blend: translucent

In effect the PR expands the set of built-in styles by bootstrapping them with the existing custom style system.

To maintain backwards compatibility, any of these bootstrapped styles is skipped if the user has already defined one with the same name.

Ideally, we would be consistent and also enable setting blend at the draw level, but this is a much more involved change due to several assumptions baked into rendering styles, e.g. each style has a single shader program, and the shaders have several #defines or other logic dependencies based on the blend mode (by comparison, blend_order only affects the CPU-side render order).

From a usage standpoint, it's arguably much more useful to set blend_order in draw, to re-order sets of features based on filters, while for blend modes it's more an issue of simply wanting to be able to use them quickly/naturally without having to first go write a boilerplate (and this enables them to effectively be set in a draw group with the style keyword).

This change has a low run-time cost. There's some parsing for these additional styles at scene load-time, but it's minimal since they contain no mixing or shader blocks. Since we now have robust on-demand shader compilation and caching by shader/program source, there should be no impact for unused styles. The main downside is that they can "pollute" the style namespace when debugging or examining all of a scene's styles programmatically.

[bcamper]

@matteblair @meetar @nvkelso thoughts on this approach?

[bcamper]

Discussed in chat.