Add ExtractableAsset trait for accessing extractable data

[beicause]

Objective

Follow-up to #21732. This attempts to provide a unified interface for extractable data. Additionally, this attempts to simplify the Mesh interface.

Solution

Adds ExtractableAsset trait and implements it for Mesh,Image,ShaderStorageBuffer. Adds is_extracted_to_render_world field to Image,ShaderStorageBuffer so that take_gpu_data doesn't need previous_gpu_asset.

Moves all try_xxx methods of Mesh to MeshExtractableData, and try_xxx_option is removed, the corresponding methods always return Option if them can. The methods on Mesh may panic. To handle panics, use extractable_data_ref / extractable_data_mut and get the MeshExtractableData interface for access.

The benefit of accessing data through the ExtractableAsset trait is you can more clearly known if the data is extractable, and you only need to check once for continuous access.

Methods accept a Mesh parameter can be changed to accept MeshExtractableData to avoid unwrap. I also added topology field to MeshExtractableData (though it won’t be extracted) and implemented Into<Mesh> for it. This makes it possible to construct a Mesh from MeshExtractableData, similar to InfallibleMesh but I’m unsure if this is a viable replacement for InfallibleMesh.

Testing

CI

[robtfm]

i've not been through in depth, but i think this approach is probably cleaner than the InfallibleMesh approach.

user code may now panic if it accesses mesh data directly, but there is a way to handle it if that user code (or engine code like mesh picking) chooses to. we don't force users to handle errors that they know can't occur on existing meshes and don't require use of a separate "builder" struct (InfallibleMesh) for avoiding impossible-error handling in primitive construction.

as written we would lose the ability to rewrite render-world-only images (previously setting image.data = Some(new_data) would successfully trigger re-upload), but assuming we get that working there's no missing functionality, less api changes, and only one significant addition (get_extractable_data_*).

[beicause]

as written we would lose the ability to rewrite render-world-only images (previously setting image.data = Some(new_data) would successfully trigger re-upload)

This can work in this PR after changing the take_gpu_data logic to use the is_extracted_to_render_world field on Image, but users must manually set this field to false after modifying to make re-uploading succeed.

[robtfm]

right, i guess it's ok to require every modification of render-world-only assets to also unset that flag.

i guess the key question is, do we intend to make render-world-only the default in future?
if we do, then maybe infallible builder plus result-handling in all other cases is better.
if not, then i think default panic, optional result-handling (i.e. this) is better.

[JMS55]

Request: For any change to extraction, please think about Solari BLAS building. It shouldn't ever be a problem, Solari operates post extract, but let's be careful.

[robtfm]

Request: For any change to extraction, please think about Solari BLAS building. It shouldn't ever be a problem, Solari operates post extract, but let's be careful.

is it possible to add an example or tests? it's the only reliable way to ensure that prs don't break stuff.