Partial alternative to D106675 to avoid the undef issues identified in PR50468 by using alternative isel patterns for vXi16/vXi32/vXi64 shl-by-one.
This affects many cases which weren't being picked up in time by combineShiftLeft() - which since this is a performance combine is probably a good thing - plus it avoids some HasOneUse issues that allows some additional optimization.
The vXi8 shl-by-one would still need to be performed using FREEZE - I don't know if anyone has concerns about having different methods?
Do we really need AddedComplexity? Especially as high as 400. The explicit immediate should automatically rank higher than any immediate.