This is the first pass at implementing an Impeller backend that restricts itself
to the feature set available in OpenGL ES 2.0. This means there is no use of
features that we will end up using where available. These features include
vertex array objects, uniform buffer objects, frame buffer discard operations,
etc..

As written, this backend should support 100% of the Android devices out in the
wild. Using VAO's and UBO's (in a future patch) where available should benefit
90.91% of the devices in the wild. Beyond that, I don't believe it makes too
much sense to invest in this backend.

This was a fairly straightforward implementation of an Impeller backend with the
following items that are perhaps unique:
* Since there are no uniform buffer objects in ES2, the offline reflector in
  `impellerc` generates additional metadata for backends like ES2 to find and
  bind uniform data in existing device buffers. Commands reference this data in
  their stage bindings but only via a pointer to a const object. Backends that
  don't need this metadata don't see any additional overhead. In the OpenGL ES
  backend, deletion of the buffers that contain uniform data is delayed till
  uniform data is bound via the glUniform* family of functions.
* Unlike Skia objects that reference GPU resources, Impeller objects can be
  created, used, and collected on any thread. All OpenGL operations happen in
  the `impeller::ReactorGLES`. This makes it easy to deal with context loss as
  we don't have to chase references to resources or ensure resources are
  collected on the right thread. Impeller resources (like textures, pipelines,
  buffers, etc.) that reference GPU resources will just reference dead handles
  on context loss and can be collected when convenient.
* Instead of not being able to use settings in high level API based on the
  backend in use, the specific settings (which were as yet unused) have been
  removed. This include `BlendOperation::kMin` and `BlendOperation::kMax` which
  require extensions in OpenGL ES 2.0. The addition of this new backend doesn't
  affect how the higher levels in the stack (like the renderer, entity, aiks,
  display_list, etc.) function.
* This backend performs an additional copy of buffer data since it need to push
  operations into the reactor. This copy will be removed when the appropriate
  APIs are updated (in a later patch) to use mappings and buffer views
  (flutter/flutter#102262). Memory usage of this
  backend will go down significantly after that patch. Even more still on
  devices where UBO's are available.
* This backend will generate separate program objects for pipeline variants.
  This makes no sense for OpenGLES as that state is set separately per draw
  call. Reusing of the same program handle for pipeline variants is as yet
  unimplemented.
* The playground test harness that was previously parameterized now has the
  `PlaygroundBackend::kOpenGLES` parameter. This effectively doubles the
  playground tests corpus.
* There is error validation after each call to OpenGL. Ideally, this should be
  moved to debug runtime modes.
* Capturing RenderDoc traces is hard in the playground because both SwiftShader
  is also linked in. Devising a strategy for capturing RenderDoc traces from the
  playgrounds is pending.

TL;DR: Backend is ready for review. Needs debugging and additional refactors
(already listed) to bring memory usage back down to baseline (relative to the
Metal backend). Existing API and backends unaffected.