This patch removes all of the Set.* methods from Status.

This cleanup is part of a series of patches that make it harder use the
anti-pattern of keeping a long-lives Status object around and updating
it while dropping any errors it contains on the floor.

This patch is largely NFC, the more interesting next steps this enables
is to:
1. remove Status.Clear()
2. assert that Status::operator=() never overwrites an error
3. remove Status::operator=()

Note that step (2) will bring 90% of the benefits for users, and step
(3) will dramatically clean up the error handling code in various
places. In the end my goal is to convert all APIs that are of the form

`    ResultTy DoFoo(Status& error)
`
to

`    llvm::Expected<ResultTy> DoFoo()
`
How to read this patch?

The interesting changes are in Status.h and Status.cpp, all other
changes are mostly

` perl -pi -e 's/\.SetErrorString/ = Status::FromErrorString/g' $(git
grep -l SetErrorString lldb/source)
`
plus the occasional manual cleanup.

This issue is reported by cppcheck as a pointless test in the watch mask
check. The `else if` condition is opposite to the previous `if`
condition, making the expression always true.

Caught by cppcheck -

lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm.cpp:509:25:
style: Expression is always true because 'else if' condition is opposite
to previous condition at line 505. [multiCondition]

Fix #91223

No one was pasing nullptr here.

Depends on D135670

Reviewed By: clayborg

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

Currently, lldb-server was opening the executable file to determine the
process architecture (to differentiate between 32 and 64 bit
architecture flavours). This isn't a particularly trustworthy source of
information (the file could have been changed since the process was
started) and it is not always available (file could be deleted or
otherwise inaccessible).

Unfortunately, ptrace does not give us a direct API to access the
process architecture, but we can still infer it via some of its
responses -- given that the general purpose register set of 64-bit
applications is larger [citation needed] than the GPR set of 32-bit
ones, we can just ask for the application GPR set and check its size.

This is what this patch does.

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

We only want iovec and uio.h is just that without a lot
of other stuff. Saves me wondering why this code might
want to open sockets.

https://pubs.opengroup.org/onlinepubs/007904975/basedefs/sys/uio.h.html

Support arbitrarily-sized FPR writes on ARM in order to fix writing qN
registers directly.  Currently, writing them works only by accident
due to value_regs splitting them into smaller writes via dN and sN
registers.

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

This patch removed some typos from NativeRegisterContextLinux_arm and
NativeRegisterContextLinux_arm64. Some of the log/error messages were
being reported as x86_64.