GH-111485: Allow arbitrary annotations on instructions and micro-ops.

[markshannon]

This allows us to be explicit about classifications of uops that are currently encoded in the code generator or analysis phase.

As an example, I've added a "specializing" annotation to denote which micro-ops specialize, rather than perform an action.
Using that we can avoid emitting the specialization code in tier 2.

A possible extension is to allow more than one annotation, but this PR only allows one for now.

• Issue: The code generated for the interpreter(s) is too fragile #111485

[gvanrossum]

Nice work, but I think the Meta folks are going to be upset that you are breaking "override". They use that feature. @itamaro @carljm

Also, test_generated_cases is now broken. One possible fix would be to add "annotation" to the set annotations in lexer.py.

[gvanrossum]

Maybe we need to add a test for override to test_generated_cases.py, so we know it doesn't rot.

[jbower-fb]

Nice work, but I think the Meta folks are going to be upset that you are breaking "override". They use that feature. @itamaro @carljm

Yes, we definitely still want this please.

Maybe we need to add a test for override to test_generated_cases.py, so we know it doesn't rot.

There were some tests, but this PR removed them.

@markshannon is there some reason override can't co-exist with annotations?

[markshannon]

Yes, we definitely still want this please.

I'll add back the functionality. I assumed it was a feature we added for development and hadn't cleaned up.
What is it for?

[markshannon]

Since it is not clear to me if and when override is used, I've change the code to allow multiple annotations per op/inst.

[jbower-fb]

Great, thank you for doing that.

The motivation for override is to make it a bit easier/safer for things like Cinder where we need to make our own tweaks to the interpreter. See #102021 where this was introduced.

[gvanrossum]

Awesome!