Mach-o has 32 bit file offsets in the MachO::section_64 structs. dSYM
files can contain sections whose start offset exceeds UINT32_MAX, which
means the MachO::section_64.offset will get truncated. We can calculate
when this happens and properly adjust the section offset to be 64 bit
safe. This means tools can get the correct section contents for large
dSYM files and allows tools that parse DWARF, like llvm-gsymutil, to be
able to load and convert these files correctly.

This reverts commit 54012102c4a8e8bba9b3b27291dab126e3521544 while I further
investigate bot failures. Apparently adding a dependence on BinaryFormat to
Object was insufficient to fix the original linker issues.

This reapplies cd32b9b6c3b, which was reverted in 25e02a43fe6 due to bot
failures.

The failures all appear to be link errors due to the Object library not
depending on BinaryFormat. This commit adds the missing dependence.

Reverts commit cd32b9b6c3b while I investigate some bot failures, e.g.
https://lab.llvm.org/buildbot/#/builders/10/builds/14784.

There's nothing ObjectFile specific about getArchTriple, so move it into
the BinaryFormat library so that clients can use it without taking a
dependence on libObject.

MachOObjectFile::getArchTriple is updated to call through to the moved
implementation.

Some error messages were spelling "children" as "childern".

The current check may fail if the addition overflows. I've observed
failures of macho-invalid.test on 32-bit due to this.

Instead, compare against the remaining bytes until the end of the
object.

ErrorAsOutParameter's Error* constructor supports cases where an Error might not
be passed in (because in the calling context it's known that this call won't
fail). Most clients always have an Error present however, and for them an Error&
overload is more convenient.

It is almost always simpler to use {} instead of std::nullopt to
initialize an empty ArrayRef. This patch changes all occurrences I could
find in LLVM itself. In future the ArrayRef(std::nullopt_t) constructor
could be deprecated or removed.

S.substr(N, M) is simpler than S.slice(N, N + M).  Also, substr is
probably better recognizable than slice thanks to
std::string_view::substr.