Bevy Asset Saving and Improvements

## What problem does this solve or what need does it fill?

Bevy Asset is currently designed around loading and processing assets, however with just a little bit of work it could be improved with additional functionality such as saving assets. This issue is to track my efforts in accomplishing this.

I have three goals:
- [x] Split `AssetSaver` into `AssetSaver` and `AssetTransformer`
- [ ] Add saving functionality to the `AssetServer`
- [ ] Add manual Asset processing

## What solution would you like?
### Split `AssetSaver` into `AssetSaver` and `AssetTransformer`
`AssetSaver` currently holds two responsibilities: processing assets and then converting them to bytes for an `AssetWriter` to save. By splitting it into two parts we can reduce code duplication and make the asset API more ergonomic.

This change will require modifying `LoadAndSave` to something like:
```rust
LoadTransformAndSave, S: AssetSaver>
```

Although this is technically a breaking change, it has a very limited surface area (just `LoadAndSave` and any custom implementations of `AssetSaver`), and a very easy migration (use `LoadTransformAndSave` and split your `AssetSaver` implementation into its two parts), so I believe that it is worth it to enable ergonomic saving and improve the Bevy Asset data model.

Note: I'm note entirely set on the name `AssetTransformer`, but `AssetProcessor` is taken. Bikeshedding is welcome on this.

### Add saving functionality to the `AssetServer`
I would like to modify the `AssetServer` to expose an API such as:
```rust
asset_server.save(path: Path, asset: Asset)
```
With events to indicate saving progress.

### Add manual Asset processing
Although the current `AssetProcessor` usage of preprocessing assets is preferable for the vast majority of use cases, it would still be handy to be able to manually process an asset from time to time. For example, transforming a `DynamicScene` to prep it for saving, or processing something once-off. I'm currently undecided about how to fit this into the API (`AssetServer`? `AssetProcessor`? Manually calling something like `AssetTransformer::transform()`?), but I will consider this further as I complete the first two tasks.

Start by reading the existing AssetSaver, LoadAndSave, AssetServer, and AssetProcessor APIs. The remaining goals are to add AssetServer saving with progress events and define an approach for manual asset processing; done means these APIs support those workflows and the design decisions are settled.

Written by the indexing model from the issue text.