Recent changes to use __int128 as an integer-like type in <ranges> and
to optimize std::uniform_int_distribution mean that the library relies
on __int128 more heavily than in the past.

The library expects that if __int128 is supported then either
__GLIBCXX_TYPE_INT_N_0 is defined (and we treat is like the standard
integer types), or __STRICT_ANSI__ is defined (and we need to add
special handling for __int128 as a non-standard integer type).

If users compile with -std=c++NN -U__STRICT_ANSI__ then it puts the
library into a broken and inconsistent state, where the compiler doesn't
define the __GLIBCXX_TYPE_INT_N_0 macro, but the library thinks it
doesn't need special handling for __int128. What the user should do is
compile with -std=gnu++NN instead.

This adds a warning if it appears that __int128 is supported but neither
__GLIBCXX_TYPE_INT_N_0 nor __STRICT_ANSI__ is defined.

libstdc++-v3/ChangeLog:

	* include/bits/c++config: Warn if __STRICT_ANSI__ state is
	inconsistent with __GLIBCXX_TYPE_INT_N_0.

Tested powerpc64-linux. Committed to trunk.