Handle extension-wide deprecatedby/supersededby attributes

[MarijnS95]

After deciding to back out of marking individual commands and types as #[deprecated] because superseding functionality is unlikely to be widely available yet, there are however niche or vendor-specific extensions that have been replaced by more common EXT/KHR extensions or even stabilized features. These would benefit from nudging the user towards the newer and/or cross-platform functionality which is more likely to be prevalent.

[MarijnS95]

Semi-draft because:

• Unsure if this is enough weight for #[deprecated] versus a doc-comment;
• promotedto is not yet handled;
• Some of these attributes are empty on the vk.xml side, resulting in an "ugly" message here;
• Call-sites still need to be updated with allow(deprecated) noise in that case.

[Ralith]

Something not right here and just above.

e: oh, yeah, you noticed too

[Ralith]

vulkan.hpp's use of this pattern gives me some confidence that it won't be hugely disruptive.

[MarijnS95]

Alternatively this could be hidden behind the same cfg_attr(feature = "pedantic_deprecated", deprecated = ...) that I described in #1038 (comment).

[Ralith]

I think extensions are usually replaced with other extensions (or core functionality) that's supported in the same places modulo driver updates, and references to extension names also aren't scattered broadly across a code base so it's easy for folks who really need to support old drivers to disable the lint, so a real deprecation annotation is less disruptive here than elsewhere.