[cpp.pragma.op] Colocate the two pragma specifications

[AlisdairM]

Moves the specification for the _Pragma operator to follow the specification for the pragma directive, to provide clearer context.

[eisenwave]

I think there's some logic to what we have right now, which is that _Pragma is last because it's a different type of feature from the usual preprocessing directives.

However, I would be slightly happier if #pragma and _Pragma were next to each other.

[AlisdairM]

I did consider whether it was intentional to sparate the operator specification from the directives specification.
I think that predefined macros coming last is not a concern, and maybe an improvement.

The only directive that gets split from the rest is the null directive, so I considered moving that to In order to avoid such splittage, but on balance chose to keep the initial PR minimal. Plus, I had at least two ideas for where the null directive might move: 1) immediately before the pragma directive, so the smallest localized change 2) make it the very first directive, getting the trivial case out of the way before jumping into more detailed features. That also inspired 3) move the error directives to the top too, giving an easy intro to the simplest directives.

All of those changes seemed more appropriate to a follow-up PR, although there was also last option that seemed too heavy handed: 4) operators and directives mix together in earlier subclauses where they are related, so open up a new parent for both the pragma directive and the pragma operator.

My personal choice would be option 3, although I have listed the 4 options in roughly the order I think would br least to most controversial :)

[jensmaurer]

Is this promised to be just-moving-text-around?

Then I'm lukewarm ok with it, although it does create rather needless inconsistency with the C presentation of the preprocessor.

For @tkoeppe to decide.

[AlisdairM]

Is this promised to be just-moving-text-around?

Yes. If someone spots a difference in the text (and I reviewed after rebasing onto a recent main) then that should be flagged and fixed before landing. I believe the current PR is correct as filed.

[tkoeppe]

I seriously struggle to muster motivation for this change. Yeah, we could, but if the shoe were on the other foot I could just as well imagine arguing for the opposite move. I'm somewhat hesitant to perform a large number of "just because we could" churn-ish permutations that don't solve any obvious defect in clarity.

[AlisdairM]

I am withdrawing this PR rather than leave it hanging in limbo.
I might revisit in the context of larger changes if we consider clause 15 a concern for #7399.