Reduce hook attribute order BC stubs to the minimum necessary

I am not saying that full revert is what we need to do, but now we have the option :) (draft MR)

We have to think a little bit what exactly we want to support:

Scenario 1:
A contrib module adds OOP hooks with #[Hook] attribute and using the order parameter.
It still wants to support older Drupal versions using by hook_module_implements_alter() and procedural hooks with the legacy attributes.
-> For this purpose, it is sufficient to backport only the order classes and the new parameter in Hook.

Scenario 2:
A contrib module introduces its own attribute classes that extend Hook.
At the same time it wants to be compatible with 10.5.x and/or 11.1.x.
-> It seems this would work fine with minimal BC stubs.

Scenario 3:
A contrib module uses the new FormAlter attribute.
At the same time it wants to be compatible with 10.5.x and/or 11.1.x.
-> This would require backport of that FormAlter attribute.

Scenario 4:
A contrib module uses the new Preprocess attribute.
At the same time it wants to be compatible with 10.5.x and/or 11.1.x.
-> This would require backport of that Preprocess attribute, AND all the new logic to register the theme hooks. So it is quite hopeless.

Scenario 5:
A contrib module or package wants to provide a functional polyfill for hook attributes, so that they work in 11.1.x and/or 10.x.
-> This would clash with any incomplete BC stubs for order classes and attributes.
-> I don't know if we care about this case.

I am adding another branch where I add what seems to be the minimum we need.
This is mostly to see our options, I am undecided myself what is the best solution here.

Which one is the one to review?

We originally backported Hook to 10.5.x so that phpstan wouldn't complain it was missing, and for no other reason, but I think slack discussion showed that's not really useful, and I reverted that commit already. The only new attribute backported to 10.5.x at this point is LegacyHook which is used in 10.5 runtime.

So... I think the remaining question is whether we want to backport any stubs to 11.1 patch releases. The reason to do this would be so that contrib can adopt e.g. FormAlter before it drops compatibility with 11.1, and not have to stay on either procedural hooks or change a Hook attribute later. It is very tempting to want to do this, but to be honest it feels like a lot of work to figure out, and every new attribute we add later we run into the same problem again.

The last patch release of 11.1 is in a couple of weeks, so I'm starting to think we should not worry about this at all, and just continue on 11.2 and later. People writing brand new modules can require >= 11.2. People who want to convert existing modules to OOP hooks can require 10.5 | >= 11.2 (at least in 2-7 months). Having to add > 11.1.7 in .info.yml already limits the feasibility of using this and maintaining 11.1 compatibility.