[InstCombine] Do not request non-splat vector support in code reviews (NFC) (#90709)

The InstCombine contributor guide already says:

> Handle non-splat vector constants if doing so is free, but do
> not add handling for them if it adds any additional complexity
> to the code.

This change strengthens this guideline to explicitly discourage
asking (new) contributors to implement non-splat support during code
reviews. Doing so will almost certainly increase the number of
necessary review iterations, or result in outright contradictory review
feedback, as different people are willing to accept a different degree
of complexity for non-splat vector support.

Author: nikic

llvm/docs/InstCombineContributorGuide.md

@@ -554,3 +554,11 @@ guidelines.
    use of ValueTracking queries. Whether this makes sense depends on the case,
    but it's usually a good idea to only handle the constant pattern first, and
    then generalize later if it seems useful.
+
+## Guidelines for reviewers
+
+ * Do not ask new contributors to implement non-splat vector support in code
+   reviews. If you think non-splat vector support for a fold is both
+   worthwhile and policy-compliant (that is, the handling would not result in
+   any appreciable increase in code complexity), implement it yourself in a
+   follow-up patch.