Reevaluate a protocols path to stability

The original purpose of "stable" vs "unstable" protocols were for unstable protocols to be able to iterate without caring about backward compatibility, then when having been "tested" in real life scenarios transition to become stable and widely used.

This has failed miserably, as multiple "unstable" protocols in practice are used extensively in multiple projects, and transitioning to a stable protocol is more of a burden than the values it provides. A few example of where "unstable" protocols have been used for a long time in production just as if it was "stable" are relative-pointer-unstable-v1, linux-dmabuf-unstable-v1 and tablet-unstable-v2.

This issue is raised to have a place to re-evaluate this, possibly replacing "stable" vs "unstable" protocols with something else.

A possible replacement for the current way of things could be:

• Make protocols be versioned "forever"
  • This would mean a future "stable" protocol would still have a _v[n] postfix in both the protocol name, as well as the interface names.
• Instead of flagging a protocol as "unstable", flag it as "staging"
  • This would mean that the z prefix would no longer be used.
  • Instead of placing the protocol in unstable/, it'd be placed in a staging/ directory in wayland-protocols.
  • Declearing a protocol as "stable" would simply be moving it from staging/ to stable/ without any changes to any interface names or protocol files.

This could potentially open up for a truly "unstable" set of protocols, that are not intended to be used in production. How to avoid such "unstable" protocols to end up being used in production is another question however.

Disclaimer: This has come up a few times on IRC and now again recently again. I stole the term "staging" directly from @emersion.