unify vk_hal::Texture::{block, external_memory} in enum TextureMemory

[s-ol]

Description
Instead of having two std::Option<> types that are logically mutually exclusive, this unifies them in an enum.

As a result, vk::Device::texture_from_raw() becomes more generic and can be used more consistently in the wgpu-hal::vulkan implementation, which also fixes inconsistent usage of the "textures" counter.

Checklist

• Run cargo fmt.
• Run taplo format.
• Run cargo clippy --tests. If applicable, add:
  • --target wasm32-unknown-unknown
• Run cargo xtask test to run tests.
• If this contains user-facing changes, add a CHANGELOG.md entry.

[s-ol]

from Matrix:

This improves the image counter situation, but I think it's still wrong - counters are incremented both on wgpu_hal::Texture creation, as well as when they are upleveled to wgpu::Texture; but they are decremented just once in wgpu::Device::destroy_texture(). However I took a brief look at other backends and they seem to follow the same inconsistent logic so I've left it alone for now in case I'm missing something about how the uplevelling works.

[Wumpf]

It seems to be a bit underdocumented how HalCounters is supposed to behave with raw textures. But looking through this it seems consistent if all textures that are injected into the system are created via texture_from_raw: wgpu-core always calls unsafe { self.raw().add_raw_texture(&*hal_texture) }; when creating a texture from hal which does the counter increment which texture_from_raw can't do because it doesn't have access to the counters.

Now I do agree that this is very wonky: if a user were to create a texture from the hal device via create_texture and then inject that texture again on the highlevel end on create_texture_from_hal we do double count that texture and never decrement. So to fix that we'd somehow need to know prior to calling add_raw_texture via which path the hal texture was created 🤔
It also really doesn't help that texture_from_d3d11_shared_handle is a lot more akin to create_texture in this regard rather than texture_from_raw. Given that this function isn't even exposed via any high level api there's definitely stuff going wrong here :/

[Wumpf]

change looks nice!
As you wrote yourself let's leave the counter kerfuffle for another iteration (with the exception of not bumping in texture_from_d3d11_shared_handle, agree that that this is better than before!).
Also CI needs fixing - a doc string has trouble

[Wumpf]

(oops, wrong button, slight changes are needed)

[s-ol]

thanks @Wumpf, I reverted the two requested hunks

[Wumpf]

thanks!
Some doc build things need attention (see ci). Otherwise good to go I think!

[s-ol]

Thanks for pointing that out, I'm still getting the hang of the contribution / CI flows here and the rust linting toolchain 🙂