load/link assets to handles defined in scene files.

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

When a scene is loaded from a file, any asset handle components attached to its entities are spawned as weak references. There is no mechanism to trigger asset loads from scene files or otherwise link handles with loaded assets. This inability to define entire scenes complete with meshes, materials, etc. is a significant roadblock to developing scene editors and other such external tooling.

## What solution would you like?

I see two potential ways to do this.

1. **The "proxy" approach**: Define a new "proxy" handle type which contains an asset path and loads the corresponding asset when the `DynamicScene` is spawned, attaching the resulting `Handle` component in its place. This would probably necessitate a special case in `DynamicScene::write_to_world` that checks if each "component" (which now would not necessarily be a component) has a special "proxy component" data type registration thing.
2. **The "link" approach**: Upgrade weak handles to strong handles at scene spawn. In general principle, "change all components that implement a certain trait based on world data" is something that the entity mapping step is already doing, so we could borrow from that feature, either by implementing a parallel feature that works similarly but independently or by unifying the two features behind a more abstract "spawn hook" feature. The scene file format would probably have to be extended to provide a way to declare asset dependencies, since the handles don't provide a full path to load assets with.

## What alternative(s) have you considered?

- The GLTF loader already produces strong `Handle`s for its meshes, materials, etc., so there are workarounds involving injecting components into the entities that it loads in. I think this is roughly what @nicopap 's [bevy scene hook](https://github.com/nicopap/bevy-scene-hook) does. This approach could potentially be aided by defining some sort of structured metadata that we look for in the GLTF file's various "extras" fields (see #2153).
- @sdfgeoff 's [blender bevy toolkit](https://github.com/sdfgeoff/blender_bevy_toolkit) does something sort of like (1) the "proxy" approach above, except the "proxies" are actually components that get loaded as normal, and are queried and resolved/replaced with a handles by special systems. The benefit of this approach is that it doesn't require modifying bevy's internals at all, but since the proxy "resolution" happens after the dynamic scene is spawned, it requires a system to be loaded at runtime for each type of asset.

## Additional context

- I have a working implementation for (1). It's a bit rough, but I could easily clean it up if we are interested in going in that direction. I made a discussion post with more details a few days ago: #4334.
- There has been some discussion surrounding reworking how scene files and assets work. See #3972 (assets), and #92, #4153 (scenes). It will be worth considering how this feature relates to future work in these areas.