[lldb][CMake] Enforce lldbUtility and lldbHost layering invariants (#198952)

lldbUtility cannot depend on any other lldb library, and lldbHost can
only depend on lldbUtility. Breaking those invariants is an easy mistake
to make and has happened repeatedly: most recently in #198931.

Because LLDB statically links its libraries on macOS, a stray LINK_LIBS
entry, or a stray cross-library #include without a matching CMake
dependency, both succeed at link time and only surface much later as a
layering bug.

Add two configure-time checks in `add_lldb_library` so the build fails
fast when these invariants are broken:

1. A new `ALLOWED_INTERNAL_DEPENDENCIES <list>` parameter allowlists
which `^lldb`-prefixed `LINK_LIBS` entries a target may depend on. The
existing `NO_INTERNAL_DEPENDENCIES` flag is the empty-allowlist case and
continues to work.

2. Whenever either of those is set, also scan the target's sources and
public headers for `#include "lldb/<Library>/..."` directives outside
the allowlist, and FATAL_ERROR with the offending file and line. This
catches the macOS static-linking case where a missing CMake dependency
silently resolves at link time.

Apply the new parameter to lldbHost (allowing only lldbUtility plus the
Darwin Objective-C++ shim lldbHostMacOSXObjCXX) and to that shim itself.
lldbUtility already used `NO_INTERNAL_DEPENDENCIES` and now picks up the
header scan automatically.

`lldb/Host/windows/windows.h` is special-cased in the scan: it is a
system-header wrapper used tree-wide and carries no real dependency.

Drop two unused `lldb/Target/*` includes from `Utility/FileSpecList.cpp`
that the scan would otherwise flag.

Assisted-by: Claude

---------

Co-authored-by: Charles Zablit <c_zablit@apple.com>