The only difference from the original PR are the added BRIEF and
FULL_DOCS arguments to define_property, which are required for
cmake<3.23.

Causes failures on several bots.

This reverts commits 714b2fdf3a385e5b9a95c435f56b1696ec3ec9e8 and
e7c1da7c8ef31c258619c1668062985e7ae83b70.

Some inter-plugin dependencies are okay, others are not. Yet others not,
but we're sort of stuck with them. The idea is to be able to prevent
backsliding while making sure that acceptable dependencies are..
accepted. For context, see
https://github.com/llvm/llvm-project/pull/139170 and the attached
changes to the documentation.

If we're not touching them, we don't need to do anything special to pass
them along -- with one important caveat: due to how cmake arguments
work, the implicitly passed arguments need to be specified before
arguments that we handle.

This isn't particularly nice, but the alternative is enumerating all
arguments that can be used by llvm_add_library and the macros it calls
(it also relies on implicit passing of some arguments to
llvm_process_sources).

A few files of lldb dir & few other files had duplicate headers
included. This patch removes those redundancies.

---------

Co-authored-by: Akash Agrawal <akashag@qti.qualcomm.com>

This reapplies https://github.com/llvm/llvm-project/pull/138892, which
was reverted in

https://github.com/llvm/llvm-project/commit/5fb9dca14aeaf12219ff149bf3a4f94c8dc58d8b
due to failures on windows.

Windows loads modules from the Process class, and it does that quite
early, and it kinda makes sense which is why I'm moving the clearing
code even earlier.

The original commit message was:

Minidump files contain explicit information about load addresses of
modules, so it can load them itself. This works on other platforms, but
fails on darwin because DynamicLoaderDarwin nukes the loaded module list
on initialization (which happens after the core file plugin has done its
work).

This used to work until
https://github.com/llvm/llvm-project/pull/109477, which enabled the
dynamic loader
plugins for minidump files in order to get them to provide access to
TLS.

Clearing the load list makes sense, but I think we could do it earlier
in the process, so that both Process and DynamicLoader plugins get a
chance to load modules. This patch does that by calling the function
early in the launch/attach/load core flows.

This fixes TestDynamicValue.py:test_from_core_file on darwin.

This reverts commit 97aa01bef770ec651c86978d137933e09221dd00 and
7e7871d3f58b9da72ca180fcd7f0d2da3f92ec4a due to failures on windows.

Minidump files contain explicit information about load addresses of
modules, so it can load them itself. This works on other platforms, but
fails on darwin because DynamicLoaderDarwin nukes the loaded module list
on initialization (which happens after the core file plugin has done its
work).

This used to work until #109477, which enabled the dynamic loader
plugins for minidump files in order to get them to provide access to
TLS.

Clearing the load list makes sense, but I think we could do it earlier
in the process, so that both Process and DynamicLoader plugins get a
chance to load modules. This patch does that by calling the function
early in the launch/attach/load core flows.

This fixes TestDynamicValue.py:test_from_core_file on darwin.

When an intra-module jump doesn't fit in the immediate branch slot, the
Darwin linker inserts "branch island" symbols, and emits code to jump
from branch island to branch island till it makes it to the actual
function.

The previous submissions failed because in that environment the linker
was putting the `foo.island` symbol at the same address as the `padding`
symbol we we emitting to make our faked-up large binary. This submission
jams a byte after the padding symbol so that the other symbols can't
overlap it.

This test is failing because when we step to what is the branch island
address and ask for its symbol, we can't resolve the symbol, and just
call it the last padding symbol plus a bajillion.

That has nothing to do with the changes in this patch, but I'll revert
this and keep trying to figure out why symbol reading on this bot is
wrong.