ArrayRef now has a new constructor that takes a parameter whose type
has data() and size().  This patch migrates:

  ArrayRef<T>(X.data(), X.size()

to:

  ArrayRef<T>(X)

These are identified by misc-include-cleaner.  I've filtered out those
that break builds.  Also, I'm staying away from llvm-config.h,
config.h, and Compiler.h, which likely cause platform- or
compiler-specific build failures.

Which fixes a test failure seen on the bots, introduced by
https://github.com/llvm/llvm-project/pull/140286.
```
[ RUN      ] OffloadingBundleTest.checkExtractOffloadBundleFatBinary
ObjectTests: ../llvm/llvm/include/llvm/ADT/StringRef.h:618: StringRef llvm::StringRef::drop_front(size_t) const: Assertion `size() >= N && "Dropping more elements than exist"' failed.
0 0x0a24a990 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/home/tcwg-buildbot/worker/clang-armv8-quick/stage1/unittests/Object/./ObjectTests+0x31a990)
1 0x0a248364 llvm::sys::RunSignalHandlers() (/home/tcwg-buildbot/worker/clang-armv8-quick/stage1/unittests/Object/./ObjectTests+0x318364)
2 0x0a24b410 SignalHandler(int, siginfo_t*, void*) Signals.cpp:0:0
3 0xf46ed6f0 __default_rt_sa_restorer ./signal/../sysdeps/unix/sysv/linux/arm/sigrestorer.S:80:0
4 0xf46ddb06 ./csu/../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:47:0
5 0xf471d292 __pthread_kill_implementation ./nptl/pthread_kill.c:44:76
6 0xf46ec840 gsignal ./signal/../sysdeps/posix/raise.c:27:6
```
Also reported on 32-bit x86.

I think the cause is the code was casting the result of StringRef.find
into an int64_t. The failure value of find is StringRef::npos, which is
defined as:
static constexpr size_t npos = ~size_t(0);

* size_t(0) is 32 bits of 0s
* the inverse of that is 32 bits of 1s
* Cast to int64_t needs to widen this, and it will preserve the original
value in doing so, which is 0xffffffff.
* The result is 0x00000000ffffffff, which is >= 0, so we keep searching
and try to go off the end of the file.

Or put another way, this equivalent function returns true when compiled
for a 32-bit system:
```
bool fn() {
    size_t foo = ~size_t(0);
    int64_t foo64 = (int64_t)foo;
    return foo64 >= 0;
}
```

Using size_t throughout fixes the problem. Also I don't see a reason it
needs to be a signed number, given that it always searches forward from
the current offset.

Utilize the new extensions to the LLVM Offloading API to extend to
llvm-objdump to handle dumping fatbin offload bundles generated by HIP.
This extension to llvm-objdump adds the option --offload-fatbin.
Specifying this option will take the input object/executable and extract
all offload fatbin bundle entries into distinct code object files with
names reflecting the source file name combined with the Bundle Entry ID.
Users can also use the --arch-name option to filter offload fatbin
bundle entries by their target triple.

---------

Co-authored-by: dsalinas <dsalinas@MKM-L1-DSALINAS.amd.com>

This reverts commit 910220b84fa18ce2cbb2e21dd53b9f3d0ae582a7.

Multiple buildbot failures have been reported:
https://github.com/llvm/llvm-project/pull/140128

Utilize the new extensions to the LLVM Offloading API to extend to
llvm-objdump to handle dumping fatbin offload bundles generated by HIP.
This extension to llvm-objdump adds the option --offload-fatbin.
Specifying this option will take the input object/executable and extract
all offload fatbin bundle entries into distinct code object files with
names reflecting the source file name combined with the Bundle Entry ID.
Users can also use the --arch-name option to filter offload fatbin
bundle entries by their target triple.

---------

Co-authored-by: dsalinas <dsalinas@MKM-L1-DSALINAS.amd.com>

This reverts commit 06d6623bc304d5fc2fe11b80b62b4c5d10f9eaa1.

Buildbot failure:
https://lab.llvm.org/buildbot/#/builders/145/builds/6871/steps/5/logs/stdio

Utilize the new extensions to the LLVM Offloading API to extend to
llvm-objdump to handle dumping fatbin offload bundles generated by HIP.
This extension to llvm-objdump adds the option --offload-fatbin.
Specifying this option will take the input object/executable and extract
all offload fatbin bundle entries into distinct code object files with
names reflecting the source file name combined with the Bundle Entry ID.
Users can also use the --arch-name option to filter offload fatbin
bundle entries by their target triple.

---------

Co-authored-by: dsalinas <dsalinas@MKM-L1-DSALINAS.amd.com>