Documentation for assetPlugins

The metro asset plugins are a powerful tool to extend the capabilities of the bundler as part of React Native mobile projects. I've used them to convert SVG source images to PNG at build time in https://github.com/aeirola/react-native-svg-asset-plugin, but found that the developer experience of building an asset plugin wasn't the best it could be, due to the lack of documentation. Similarly, looking at the marginal community effort for building asset plugins, I think better documentation could inspire more community members to extend the React Native build time tooling with new asset plugins.

So I'm proposing the addition of documentation around asset plugins. This could include both API reference documentation and more verbose guides for potential asset plugin developers. In the reference documentation I would be happy to see things like:

• When and how the bundler loads and calls the asset plugin
• What data is passed to the asset plugin
• What data is expected to be returned by the asset plugin
• How the bundler cache affects the asset plugin behaviour

For an asset plugin developer guide it would be interesting to see broader discussion on the topics of:

• Templates / examples of asset simple plugins
• Best practices on how to cache and store any derivative asset files
• Providing configuration of asset plugins

If this is something that resonates with the maintainers of metro, I'd be happy to help out with producing the documentation based on my own experiences of writing asset plugins. Since my knowledge in the area is only based on my own studies of the bundler codebase and types, I might not get all the essential details correct. Thus I would ask for at least some support from maintainers in ensuring that any produced documentation wouldn't be misleading or contradictory to any possible future plans of metro.

Start by reviewing the Metro bundler codebase and types that define asset plugins, focusing on when they are loaded, their inputs and outputs, and cache behavior. Use those details to outline API reference documentation and a developer guide covering examples, derivative-asset caching, and configuration. Done means the documentation is accurate and maintainers have confirmed it does not conflict with future Metro plans.