Identified with misc-include-cleaner.

I'm planning to remove StringRef::equals in favor of
StringRef::operator==.

- StringRef::operator==/!= outnumber StringRef::equals by a factor of
  70 under llvm/ in terms of their usage.

- The elimination of StringRef::equals brings StringRef closer to
  std::string_view, which has operator== but not equals.

- S == "foo" is more readable than S.equals("foo"), especially for
  !Long.Expression.equals("str") vs Long.Expression != "str".

Note that llvm::support::endianness has been renamed to
llvm::endianness while becoming an enum class as opposed to an
enum. This patch replaces support::{big,little,native} with
llvm::endianness::{big,little,native}.

The last template parameter of llvm::support::endian::{read,write}
defaults to unaligned, so we can drop that at call sites.

Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D149440

Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D149439

Similar to D125411, but for ARM64X.

ARM64X PE binaries are hybrids containing both ARM64EC and pure ARM64
variants in one file. They are usually linked by passing separate
ARM64EC and ARM64 object files to linker. Linked binaries use ARM64
machine and contain additional CHPE metadata in their load config.
CHPE metadata support is not part of this patch, I plan to send that later.

Using ARM64X as a machine type of object files themselves is somewhat
ambiguous, but such files are allowed by MSVC. It treats them as ARM64
or ARM64EC object, depending on the context. Such objects can be
produced with cvtres.exe -machine:arm64x.

Reviewed By: efriedma

Differential Revision: https://reviews.llvm.org/D148517