When `convertToInteger` fails, the integer result is undefined. In this
case, we cannot use it in the subsequent steps.
Close https://github.com/llvm/llvm-project/issues/167627.

Introduce members() iterator-helper to shorten the members_{begin,end}
idiom. A previous attempt of this patch was #130319, which had to be
reverted due to unit-test failures when attempting to call members() on
the end iterator. In this patch, members() accepts either an ECValue or
an ElemTy, which is more intuitive and doesn't suffer from the same
issue.

Currently iterators over EquivalenceClasses will iterate over std::set,
which guarantees the order specified by the comperator. Unfortunately in
many cases, EquivalenceClasses are used with pointers, so iterating over
std::set of pointers will not be deterministic across runs.

There are multiple places that explicitly try to sort the equivalence
classes before using them to try to get a deterministic order
(LowerTypeTests, SplitModule), but there are others that do not at the
moment and this can result at least in non-determinstic value naming in
Float2Int.

This patch updates EquivalenceClasses to keep track of all members via a
extra SmallVector and removes code from LowerTypeTests and SplitModule
to sort the classes before processing.

Overall it looks like compile-time slightly decreases in most cases, but
close to noise:

https://llvm-compile-time-tracker.com/compare.php?from=7d441d9892295a6eb8aaf481e1715f039f6f224f&to=b0c2ac67a88d3ef86987e2f82115ea0170675a17&stat=instructions

PR: https://github.com/llvm/llvm-project/pull/134075

Remove a level of indirection and update code to use range-based for
loops.

Similar to https://github.com/llvm/llvm-project/pull/96902, this adds
`getDataLayout()` helpers to Function and GlobalValue, replacing the
current `getParent()->getDataLayout()` pattern.

Originally reverted because of a bug in Range that is now fixed
(#86041), we can reland this commit. Tests have been added to ensure the
miscompile that caused the revert does not happen again.

The MinBW was being calculated using the significant bits of the upper
and lower bounds. The upper bound is 1 past the last value in the range
so I don't think it should be included. Instead use ConstantRange::getMinSignedBits.

I'm still not sure if the +1 is needed after the getMinSignedBits call.

Reverts llvm/llvm-project#79158, which causes a miscompile. See
https://github.com/llvm/llvm-project/pull/79158#issuecomment-2007842032