Document GlobalISel's combiner guidelines

[aemerson]

@tschuett made a good point that our approach to writing combiners in GlobalISel needs some documentation here: #91922

This issue is to track that initial work on elaborating things like:

• Combiner best practices
• Rationales for what we do
• Artifact vs regular combiner
• Notable exceptions to the above and why they're there

[tschuett]

I vote for a section about the combiner design. We compile the Combine.td into a matchable. 10 more lines.

Complex logic is delegated to CombinerHelper Helper.

From this design, we can conclude:

• Keep as much logic as possible in Combine.td and less logic in the Helper => lower compile time.
• visit functions are an anti pattern. They delegate too much logic into the helper => higher compile time.
• Many tight, precise, and small combines for lower compile time and targets can pick the choices.

[tschuett]

We are not rebuilding InstCombine. We take inspirations from InstCombine. If there are semantic uncertainties, we take InstCombine as the reference.

[tschuett]

Assuming the combiner is at least an artefact combiner, the AArch64 post legalization combiner is too weak, see
#101327 (comment)

[tschuett]

We should/must combine ADDEs post legalization, but we don't.

[tschuett]

To make a secret public, I have some interest in https://reviews.llvm.org/D96031. If this is a legacy way of doing combines and the rules changed, we should document that and make the rules public.

#90618 is plain port from InstCombine, which I believe was a great idea and big win for us.