This is in preparation for the new MultiMemRead packet discussed in the
RFC [1].

An alternative to using `qSupported` would be having clients send an
empty `MultiMemRead` packet. However, this is problematic because the
already-existing packet `M` is a prefix of `MultiMemRead`; an empty
reply would be ambiguous in this case. It is also risky that the stub
might interpret the `MultiMemRead` as a valid `M` packet.

Another advantage of `qSupported` is that this packet is already
exchanged, so parsing a new field is simpler than having to exchange one
extra packet.

[1]:
https://discourse.llvm.org/t/rfc-a-new-vectorized-memory-read-packet/88441

This fixes issues found in e066f35c6981c720e3a7e5883efc40c861b3b7, which
was later reverted. The problem was with "k" message which was sent with
sync_on_timeout flag set to true, so lldb was waiting for response,
which is currently not being sent by lldb-server. Not waiting for
response at all seems to be not a solution, because on MAC OS X lldb
waits for response from "k" to gracefully kill inferior.

Temporarily revert commit e066f35c6981c720e3a7e5883efc40c861b3b7ee,
because lldb tests randomly hang after it's been pushed.

Patch fixes the sync-on-timeout logic in lldb and switches to qEcho
based ping, instead of qC. This fixes vRun message case, when there is
no process yet and qC returns an error.

'isconnect' I assume was supposed to be 'disconnect'.

I *think* this was the reason behind the failures in
2fd860c1f559c0b0be66cc000e38270a04d0a1a3: the clang include tool showed
the Config.h headers as unused, and because the macro was referenced
through an `#ifdef`, its removal didn't cause build failures. Switching
to `#cmakedefine01` + `#if` should make sure this does not happen again.

According to D48977, the `#ifndef`+`#cmakedefine` patterns is due to
some files redefining the macro themselves. I no longer see any such
files in the source tree (there also were no files like that in the
source tree at the revision mentioned, but the macro *was* defined in
the hand-maintained XCode project we had at the time).

This reverts commit
https://github.com/llvm/llvm-project/commit/87b7f63a117c340a6d9ca47959335fd7ef6c7ad2,
reapplying

https://github.com/llvm/llvm-project/commit/7e66cf74fb4e6a103f923e34700a7b6f20ac2a9b
with a small (and probably temporary)
change to generate more debug info to help with diagnosing buildbot
issues.

This reverts commit 7e66cf74fb4e6a103f923e34700a7b6f20ac2a9b.

Breaking green dragon:

https://green.lab.llvm.org/job/llvm.org/view/LLDB/job/as-lldb-cmake/19569/testReport/junit/lldb-api/functionalities_reverse-execution/TestReverseContinueWatchpoints_py/

This reverts commit a774de807e56c1147d4630bfec3110c11d41776e.

This is the same changes as last time, plus:
* We load the binary into the target object so that on Windows, we can
resolve the locations of the functions.
* We now assert that each required breakpoint has at least 1 location,
to prevent an issue like that in the future.
* We are less strict about the unsupported error message, because it
prints "error: windows" on Windows instead of "error: gdb-remote".