WIP: Support extern context impl

[sagudev]

Connections
Based on #6619, fixes #6330

Description
This PR enables users of wgpu to provide custom Instance impl (and other wgpu types as all other types are derived from Instance->Adapter->Device), by adding Custom variant and custom backend that has dyn wrapper for all types: struct DynDevice(Arc<dyn DeviceInterface>). I'm intermixing Custom with Dyn because I cannot really decide on name (CustomDevice is weird, but we already have Dyn* in wgpu-hal).
There are few rough sports:

• RenderBundleEncoderInterface::finish (other backends hacks around by not using dyn dispatch, but we can't:

  wgpu/wgpu/src/api/render_bundle_encoder.rs

  Lines 54 to 60 in b876b8c

  	pub fn finish(self, desc: &RenderBundleDescriptor<'_>) -> RenderBundle {
  	let bundle = match self.inner {
  	#[cfg(wgpu_core)]
  	dispatch::DispatchRenderBundleEncoder::Core(b) => b.finish(desc),
  	#[cfg(webgpu)]
  	dispatch::DispatchRenderBundleEncoder::WebGPU(b) => b.finish(desc),
  	};

• InstanceInterface::new cannot work because we cannot use dyn dispatch to create new instance (instance must be created by consumer)
• webgpu only methods are unimplemented!

future work:

• allow wgpu on native to be without core (libraries using wgpu (ex: vello) usually get instance/device from their users, so they would want to disable core if user is providing instance anyway), although this make wgpu to play 2 roles: abstraction provider and impl provider (of core and webgpu backend). Should we somehow split this into two creates? (so libraries would only depend on wgpu-abstract while consumers of those libraries would use wgpu-provider that would also depend on wgpu-abstract and toggle appropriate features for enums: core,webgpu,custom)

Testing
For testing we simply pass wgpu-core/webgpu as dyn Instance (be5acfa), so this works, but I plan to do example of creating dummy interface (for testing purposes).

Checklist

• Run cargo fmt.
• Run taplo format.
• Run cargo clippy. If applicable, add:
  • --target wasm32-unknown-unknown
  • --target wasm32-unknown-emscripten
• Run cargo xtask test to run tests.
• Add change to CHANGELOG.md. See simple instructions inside file.

[sagudev]

TBH, I have no idea what's wrong with WASM.

[sagudev]

This is triggering visibility problems for WASM, but I do not know why.

[cwfitzgerald]

Ping me if this needs looking at or you need help before it is out of draft, going to un-assign myself for bookeeeping

[sagudev]

In 79ecded I removed InterfaceTypes trait as it's not really needed anymore (this makes writing Custom/Dyn wrappers easier as they do not need to impl traits directly, avoiding a lot of boilerplate), all bounds are actually enforced in dispatch_types_inner anyway. The only useful application was making writing macros easier, but I replaced this with mod interface_types that has aliases for interface types (there is a lot of this pattern in servo as it was used before associate trait types), but we could also just write more stuff in macro and remove the completely. Does approach like this sounds reasonable @cwfitzgerald? I would be willing to split this into separate PR if it's ok.

[cwfitzgerald]

Hmm... I don't love it as it makes things less structured, but can't see a strong argument against removing the trait. Will fully consider it when I review this. You can leave it as part of this PR for now.

[sagudev]

I have alternative approach in sagudev@ce58280 which keeps the trait but instead of using interfaces in bounds it uses Dispatch<Target = dyn Interface> (clone of Deref trait, I avoid Deref to avoid compiler magic as it makes bounds less explicit esp between Dispatch and DispatchMut). One thing to consider here is that implementations of custom context will need to provide all types, even those that are not needed (ex. if one does not need/use compute pass). Should I switch to this approach @cwfitzgerald?