Layer API

`pxl` intentionally provides a limited, pixel-based rendering API. The intention is that this API be extremely easy to learn and use.

Any kind of rendering can be implemented on top of the pixel-based rendering API, but since it is an unaccelerated CPU-side API, performance may not be acceptable at higher resolutions.

It would be nice to provide access to GPU-accelerated drawing APIs, but these APIs tend to be very complex, and my subjective feeling is that there aren't any clear standouts in the rust ecosystem that I would feel comfortable exposing `pxl` users to directly.

My idea to deal this is to provide hooks for the implementation of rendering "layers" in `pxl`. These rendering layers may allow the user to use an existing API, or present a completely new one. Rendering layers may employ a variety of rendering techniques, with the one restriction being that they must render into a given framebuffer.

Then, the output of the various layers may be combined by a user-provided shader, which accesses them as textures and composites them to the default framebuffer for display.

The current pxl runtime (which may be split into a separate crate named `pxl-native` or `pxl-gl`) uses OpenGL as a back end, so the layer API will likely expose an OpenGL context and destination OpenGL framebuffer.

Individual layers will be provided as separate crates, so `pxl` API backwards compatibility need not be tied to layer API backwards compatibility.

Some ideas for layers that I would like to provide are:
- GPU accelerated tile and sprite rendering layer
- GPU accelerated graphics/path/text rendering (skia, probably)
- Dear-imgui UI layer for UI rendering
- A higher-level 3D rendering engine, such as `three-rs`
- A raw OpenGL layer, or possibly a layer exposing a glium context

The layer API itself will need to provide:
- Access to the OpenGL context
- A framebuffer/texture to render to
- The ability for users to select which layers to use and access their instances for rendering
- A mechanism to control which layers are bound to which textures, so the compositing shader can combine the layer outputs for display
- The ability to override the default compositing shader

Start by reviewing the current pxl runtime and its OpenGL backend, since the issue does not name specific files or tests. Define how layers access the OpenGL context and destination framebuffer, how their outputs are bound as textures, and how users select layers. Done means the layer API supports compositing and overriding the default shader while preserving the existing pixel API.

Written by the indexing model from the issue text.