Remove DUMMY_MESH_MATERIAL

[greeble-dev]

Objective

Progress #19024 by avoiding AssetId::invalid. This helps assets-as-entities, and may help with future render optimizations as it's one step towards reducing AssetId to an Entity.

Solution

Previously, RenderMeshInstances::mesh_material would return an UntypedAssetId. The magic value DUMMY_MESH_MATERIAL would signal "not found". DUMMY_MESH_MATERIAL was equal to AssetId::<StandardMaterial>::invalid().

This PR makes RenderMeshInstances::mesh_material return Option<UntypedAssetId>, so "not found" becomes None.

Testing

Tested on Native/Win10 and WASM/Chrome/Win10/WebGL. This covers both the CPU and GPU mesh paths.

cargo run --example specialized_mesh_pipeline
cargo run --example testbed_3d
cargo run --example meshlet --features "meshlet meshlet_processor https free_camera"

Performance

Tested many_foxes with CPU and GPU mesh paths. Difference was below the noise floor (<5%). Probably a very minor optimization if it replaces a full UntypedAssetId comparison with an is_none.

[greeble-dev]

There's potential for a subtle behavior change if render_material_bindings somehow contained a DUMMY_MESH_MATERIAL with a non-default material binding. But that seems unlikely, and the new behavior is arguably more correct.

[andriyDev]

We explicitly state that assigning to ::invalid() results in "undefined behavior" (I don't like the wording but the words are correct). So if that's what you mean by "non-default material binding" I think it's ok.

[andriyDev]

@IceSentry you've been working on rendering perf, so you might care to look at this? Not sure if we're down to counting branches there :P

[andriyDev]

We explicitly state that assigning to ::invalid() results in "undefined behavior" (I don't like the wording but the words are correct). So if that's what you mean by "non-default material binding" I think it's ok.

[alice-i-cecile]

Waiting on a full rendering review before merging.