rustc_pattern_analysis: always check that deref patterns don't match on the same place as normal constructors

[dianne]

In #140106, deref pattern validation was tied to the deref_patterns feature to temporarily avoid affecting perf. However:

• As of remove special-casing of boxes from match exhaustiveness/usefulness analysis #143414, box patterns are represented as deref patterns in rustc_pattern_analysis. Since they can be used by enabling box_patterns instead of deref_patterns, it was possible for them to skip validation, resulting in an ICE. This fixes that and adds a regression test.
• External tooling (e.g. rust-analyzer) will also need to validate matches containing deref patterns, which was not possible. This fixes that by making compute_match_usefulness validate deref patterns by default.

In order to avoid doing an extra pass for anything with patterns, the second commit makes RustcPatCtxt keep track of whether it encounters a deref pattern, so that it only does the check if so. This is purely for performance. If the perf impact of the first commit is negligible and the complexity cost introduced by the second commit is significant, it may be worth dropping the latter.

r? @Nadrieril

[rustbot]

Nadrieril is currently at their maximum review capacity.
They may take a while to respond.

[rustbot]

Some changes occurred in exhaustiveness checking

cc @Nadrieril

rust-analyzer is developed in its own repository. If possible, consider making this change to rust-lang/rust-analyzer instead.

cc @rust-lang/rust-analyzer

Some changes occurred in match checking

cc @Nadrieril

[Nadrieril]

Do you want to try keeping just the first commit so we can do a perf run? Mostly out of curiosity, second commit looks good to me.