deprecate precedence of & and |. for #5187

[JeffBezanson]

This will allow us to change the precedence of these operators.

This change is certainly unnatural for bit twiddling; writing x & mask == 0 you definitely expect & to happen first. We do more bit masking in Base than I expected.

What should we do about ⊻? Here it still has + precedence, but it seems a bit odd for it to have wildly different precedence than & and |.

[vtjnash]

What should we do about...

It seems this PR partially also introduces support for detecting "ambiguous precedence"? I think I'm vaguely in favor of just requiring parens around some of the other combinations of operations (I'm mainly thinking of combinations of bitwise and arithmetic operators here, like a + b << c).

[Sacha0]

One of the things that #25180 taught me is that defensive parens seem the rule rather than the exception, so I am vaguely with @vtjnash :).

[JeffBezanson]

Yes, after this experience I agree we should have ambiguous precedence errors and maybe some cases of non-transitive precedence.

[ararslan]

Precedence change aside, I just want to point out how much clearer I think the code looks with parentheses for these operations. 👍

[JeffBezanson]

Triage prefers .&& and .|| for the original desired application of this, which can be added later non-breaking.

We also would like to have ambiguous precedence errors at some point in the future, but it seems a bit half-assed to only add this for & and | right now. Can be added during 1.x by having the warnings off by default and opt-in until 2.0.

[fredrikekre]

The added parenthesis helps with visual parsing IMO, worth merging that?