Add a Dummy backend

[kvark]

Is your feature request related to a problem? Please describe.
Users may sometimes want to compile against wgpu some code that's never executed. In this case, they don't want to have any of the dependencies, just the API.

Describe the solution you'd like
Add a "dummy" backend (behind a feature) to wgpu-rs.

Describe alternatives you've considered
Having backend selection be done with features in wgpu and wgpu-core, so that these users can select no backends.

Additional context
#1221 (comment)

[Shatur]

Are you planning to look into this feature? I'm interested in this and would like to contribute, but I don't know wgpu architecture. But I could try if you give me some hints :)

[kvark]

I'm not planning to get to this right now, but will happily accept contribution. Just look at other wgpu/src/backend/ things and follow? You can start by copy pasting, say, the web backend and just removing implementations.

[Shatur]

@kvark how this feature should look? Features can't remove dependencies. So should we have a native-header in default features and use dummy backend if it disabled? Please, advice :)

[kvark]

We talked about this on Matrix and found no good solution. Also, this problem applies to "webgpu-headers" backend (which we need to add), not just to the dummy one.
Issue: if "dummy" is an optional feature, there is no way to disable wgpu-core dependency. If it needs to be disabled, it needs to become an optional feature itself, presumably enabled by default. This will unlikely affect any regular users (since they will get this feature by default).
However, for the use case of @Shatur this will not be enough. If there are any crates between Bevy and wgpu, they'd have to know how to disable the optional features of wgpu as well. This seems like a world of pain...

[Shatur]

Thanks for the info! Will think about a solution on Bevy side.

[cwfitzgerald]

We've already done this, wgpu-hal has a dummy backend.