Revert "[SCEV][NFC] Check NoWrap flags before lexicographical comparison of SCEVs"

This reverts r319889.

Unfortunately, wrapping flags are not a part of SCEV's identity (they

do not participate in computing a hash value or in equality

comparisons) and in fact they could be assigned after the fact w/o

rebuilding a SCEV.

Grep for const_cast's to see quite a few of examples, apparently all

for AddRec's at the moment.

So, if 2 expressions get built in 2 slightly different ways: one with

flags set in the beginning, the other with the flags attached later

on, we may end up with 2 expressions which are exactly the same but

have their operands swapped in one of the commutative N-ary

expressions, and at least one of them will have "sorted by complexity"

invariant broken.

2 identical SCEV's won't compare equal by pointer comparison as they

are supposed to.

A real-world reproducer is added as a regression test: the issue

described causes 2 identical SCEV expressions to have different order

of operands and therefore compare not equal, which in its turn

prevents LoadStoreVectorizer from vectorizing a pair of consecutive

loads.

On a larger example (the source of the test attached, which is a

bugpoint) I have seen even weirder behavior: adding a constant to an

existing SCEV changes the order of the existing terms, for instance,

getAddExpr(1, ((A * B) + (C * D))) returns (1 + (C * D) + (A * B)).

Differential Revision: https://reviews.llvm.org/D40645