Normalize VARYING for -fstrict-enums.

The problem here is that the representation for VARYING in
-fstrict-enums is different between value_range and irange.

The helper function irange::normalize_min_max() will normalize to
VARYING only if setting the range to the entire domain of the
underlying type.  That is, [0, 0xff..ff], not the domain as defined by
-fstrict-enums.  This causes problems because the multi-range version
of varying_p() will return true if the range is the domain as defined
by -fstrict-enums.  Thus, normalize_min_max and varying_p have
different concepts of varying for multi-ranges.

(BTW, legacy ranges are different because they never look at the
extremes of a range to determine varying-ness.  They only look at the
kind field.)

One approach is to change all the code to limit ranges to the domain
in the -fstrict-enums world, but this won't work because there are
various instances of gimple where the values assigned or compared are
beyond the limits of TYPE_{MIN,MAX}_VALUE.  One example is the
addition of 0xffffffff to represent subtraction.

This patch fixes multi-range varying_p() and set_varying() to agree
with the normalization code, using the extremes of the underlying type,
to represent varying.

gcc/ChangeLog:

	PR tree-optimization/97767
	* value-range.cc (dump_bound_with_infinite_markers): Use
	wi::min_value and wi::max_value.
	(range_tests_strict_enum): New.
	(range_tests): Call range_tests_strict_enum.
	* value-range.h (irange::varying_p): Use wi::min_value
	and wi::max_value.
	(irange::set_varying): Same.
	(irange::normalize_min_max): Remove comment.

gcc/testsuite/ChangeLog:

	* g++.dg/opt/pr97767.C: New test.