vect: Tighten vect_determine_precisions_from_range [PR113281]

This was another PR caused by the way that
vect_determine_precisions_from_range handles shifts.  We tried to
narrow 32768 >> x to a 16-bit shift based on range information for
the inputs and outputs, with vect_recog_over_widening_pattern
(after PR110828) adjusting the shift amount.  But this doesn't
work for the case where x is in [16, 31], since then 32-bit
32768 >> x is a well-defined zero, whereas no well-defined
16-bit 32768 >> y will produce 0.

We could perhaps generate x < 16 ? 32768 >> x : 0 instead,
but since vect_determine_precisions_from_range was never really
supposed to rely on fix-ups, it seems better to fix that instead.

The patch also makes the code more selective about which codes
can be narrowed based on input and output ranges.  This showed
that vect_truncatable_operation_p was missing cases for
BIT_NOT_EXPR (equivalent to BIT_XOR_EXPR of -1) and NEGATE_EXPR
(equivalent to BIT_NOT_EXPR followed by a PLUS_EXPR of 1).

pr113281-1.c is the original testcase.  pr113281-[23].c failed
before the patch due to overly optimistic narrowing.  pr113281-[45].c
previously passed and are meant to protect against accidental
optimisation regressions.

gcc/
	PR target/113281
	* tree-vect-patterns.cc (vect_recog_over_widening_pattern): Remove
	workaround for right shifts.
	(vect_truncatable_operation_p): Handle NEGATE_EXPR and BIT_NOT_EXPR.
	(vect_determine_precisions_from_range): Be more selective about
	which codes can be narrowed based on their input and output ranges.
	For shifts, require at least one more bit of precision than the
	maximum shift amount.

gcc/testsuite/
	PR target/113281
	* gcc.dg/vect/pr113281-1.c: New test.
	* gcc.dg/vect/pr113281-2.c: Likewise.
	* gcc.dg/vect/pr113281-3.c: Likewise.
	* gcc.dg/vect/pr113281-4.c: Likewise.
	* gcc.dg/vect/pr113281-5.c: Likewise.