Texture atlas preprocessing & the art production pipeline.

In order to make Bevy a tier 1 engine for 2D games, a better texture atlas art production pipeline is needed.

Requirements:

- It should be possible to drop texture atlas source art into a directory and have the asset preprocessor rebuild the atlas.
- In this sense, the individual source art is uncooked and the atlas is a cooked (shippable) asset.
- More texture atlas services should be exposed through this preprocessing (and the underlying API).
- Preprocessing should be resilient to bad data, communicating the nature of the error without panics. Cooking content should be a viable runtime development activity by non-programmers on the team.

Additional Features:

- The atlas preprocessor should be configurable.
- Option: Trim whitespace. To pack efficiently, the asset preprocessor should be able to trim whitespace and record in metadata the amount trimmed so that the original UVs can be reconstructed.
- Option: Rotate images. To pack efficiently, the asset preprocessor should be able to rotate images 90deg and record in the metadata the rotation bit so that the original UVs can be reconstructed.
- Option: Paginated atlases. It should be possible to specify the max texture size of an atlas and, if the source art exceeds this arrangement, produce additional atlas pages. Meta data would track this and use the appropriate texture binding at render time.
- Option: Resampling rules. It may be useful to be able to specify resampling rules for input images before they are written to the atlas.

Many of these are features of the Esoteric atlas packer, which is very good.

No files, tests, or entry points are named. Start by locating the existing texture atlas asset preprocessing and underlying API, then determine how source art, cooked atlases, metadata, and errors are currently handled. Done means the proposed pipeline covers rebuilding, configuration, metadata, pagination, and resilient error reporting.

Written by the indexing model from the issue text.