generator: Do not generate code for "disabled" extensions

[MarijnS95]

It is unlikely that disabled, reserved extensions (without naming whatsoever) are used through Ash bindings generated from Vulkan-Headers releases, and are best ignored to reduce diff noise and spurious issues 1 with unfinished extension definitions.

This approach matches what is defined in the registry spec for supported="disabled" 2:

use `supported="disabled"` to indicate this extension should never be processed.

---

Let me know if someone is using our bindings to access in-development extensions through these means though! (But in that case I expect a local substitution in vk.xml + regeneration...)

[MarijnS95]

Whoops, should have ran cargo check, this fails to compile for the same reason as #417 (comment) :/

We should either:

1. Exempt some well-defined but disabled extensions from this check (only VK_ANDROID_native_buffer for now);
2. Fold extension-types with their extension (scheduled for the new generator as it's quite an overhaul, see linked comment above);
3. Not do this at all, accept the numbered extensions and skip 1.2.180 until vk.xml is fixed (or - unlikely - skip the broken extension if someone absolutely needs 1.2.180).

[Ralith]

Looks like some unrelated updates got mixed in?

[MarijnS95]

Looks like I either forgot to re-sync the submodule to 1.3.235, or base this on top of #688. It's self-supporting now on 1.3.235.

EDIT: And in the force-push I forgot to update the readme yet again.

[Ralith]

Nice!