wayland-scanner: Support deprecated-since

[bbb651]

Parses deprecated-since attributes in requests/events/entries, and generates #[deprecated]s. Note that this only happens for the client side, since servers are expected to support protocols indefinitely (P.S. should this be added to the description, if so only on the server side?)

The deprecations themselves also generate warnings for the wayland-protocols* crates, I'm not totally sure where the #[allow(deprecated)] should be and it feels silly to add them to every interface so I currently only put it for the core protocol (which iirc is the only place they are used so far), from what I see this is also a problem for missing_docs.

This needs some more testing, I only really tested AxisDiscrete.

[ids1024]

Note that this only happens for the client side, since servers are expected to support protocols indefinitely (P.S. should this be added to the description, if so only on the server side?)

Client may also want want to support old protocol version... if not indefinitely, at least for a fairly long time (it can take a while for all compositors to support a new version, then be released, then be in distros; and applications may want to target old LTS distros that presumably won't update the compositor with new features).

So this is a bit different from what #[deprecated] usually means in a Rust library.

[bbb651]

I agree, the meaning is different because the version of the interface is not tied to the version of the crate, this is also why we can't use the actual since field.
I still think it's a good idea even if you'll often have to often #[allow(deprecation)] for these items - it makes it very visible that it is deprecated when writing the code in autocompletion, and placing the attribute is a subtle reminder that it should be removed at some point.
For the AxisDiscrete example, the AxisValue120 event that replaces it was added in the same version AxisDiscrete was deprecated, and the event is no longer sent to versions requesting that interface. But if you happen to request (I assume requesting means the minimum?) version 8 or above, it'll never be sent and it be more obvious why with the deprecation.

The closet example I can think of is web-sys, you also have the same problem of using newer apis because of backwards compatibility with browsers, though they are much more conservative with deprecations, it seems like they don't surface deprecation information at all currently, but in the javascript ecosystem it does even thought it's different in the same way. Another non-rust example I can think of is the android api, they also deprecate system apis but you might still use them for years for device support.

Worst case we can keep them both as documentation text in a more prominent and structured way than the existing descriptions.