DynamicLoaderWindowsDYLD uses pointers to Modules to maintain a map
from modules to their addresses, but it does not need to keep "strong"
references to them. Weak pointers should be enough, and would allow
modules to be released elsewhere.
Other DynamicLoader classes do not use shared pointers as well. For
example, DynamicLoaderPOSIXDYLD has a similar map with weak pointers.
Actually testing for modules being completely released can be tricky.
The test here is just to illustrate the case where shared pointers kept
modules in DynamicLoaderWindowsDYLD and prevented them from being
released. The test executes the following sequence:
1. Create a target, load an executable and run it.
2. Remove one module from the target. The target should be the last
actual use of the module, but we have another reference to it in the
shared module cache.
3. Call MemoryPressureDetected to remove this last reference from the
cache.
4. Replace the corresponding DLL file.
LLDB memory maps DLLs, and this makes files read-only on Windows. Unless
the modules are completely released (and therefore unmapped), (4) is
going to fail with "access denied".
However, the test does not trigger the bug completely - it passes with
and without the change.
When running a process that would exit before LLDB could stop the
target, it would try to interpret (and subsequently format) the exit
code as a Win32 error. However, processes on Windows won't return Win32
errors in that case. They will often return an
[NTSTATUS](https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-erref/596a1078-e883-4972-9bbc-49e60bebca55).
One common case for this to occur is when a DLL is missing. In that
case, the process will start successfully, but it will exit with
`STATUS_DLL_NOT_FOUND`.
LLDB would previously return "unknown error", because it tried to
[`FormatMessage`](https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-formatmessage)
`0xC0000135` which doesn't work, so it fell back to "unknown error".
This PR changes the error to be the string "Process prematurely exited
with {0:x}" and doesn't try to format the exit code. One could
`FormatMessage` an `NTSTATUS` by passing `FORMAT_MESSAGE_FROM_HMODULE`
and a handle to `ntdll.dll`, however, I don't think we can get the
required format arguments (e.g. the missing DLL name - `%hs`).
