The motivation for this patch is that
`StopInfo::GetSuggestedStackFrameIndex` would not take effect for
`InstrumentationRuntimeStopInfo` (which we plan to implement in
https://github.com/llvm/llvm-project/pull/133079). This was happening
because the instrumentation runtime plugins would run utility
expressions as part of the stop that would set the
`m_selected_frame_idx`. This means `SelectMostRelevantFrame` was never
called, and we would not be able to report the selected frame via the
`StopInfo` object.

This patch makes sure we clear the `m_selected_frame_idx` to allow
`GetSuggestedStackFrameIndex` to take effect, regardless of what the
frame recognizers choose to do.

This patch uses the "setting changed" callback to clear previously
cached stack frames when
`target.process.disable-language-runtime-unwindplans` is changed. This
is necessary so that changing the setting followed by a `backtrace`
command produces an accurate backtrace.

With this, a user can create a custom command like below in order to
quickly inspect a backtrace created without language plugins.

```
debugger.HandleCommand("settings set target.process.disable-language-runtime-unwindplans true")
debugger.HandleCommand("bt " + command)
debugger.HandleCommand("settings set target.process.disable-language-runtime-unwindplans false")
```

In the future, we may consider implementing this as an option to
`backtrace`. Currently, this process setting is the only way of
affecting the unwinder, and changing the process setting as part of the
backtrace implementation doesn't feel right.

There are no upstream users of this flag, so we cannot write a test for
it here.

This is an odd corner case of the use of scripts loaded from dSYM's - a
macOS only feature, which can load OS Plugins that re-present the thread
state of the program we attach to. If we find out about and load the
dSYM scripts when we discover a target in the course of attaching to it,
we can end up running the OS plugin before we've started up the private
state thread. However, the os_plugin in that case will be running before
we broadcast the stop event to the public event listener. So it should
formally use the private state and not the public state for the Python
code environment.

This patch says that if we have not yet started up the private state
thread, then any thread that is servicing events is doing so on behalf
of the private state machinery, and should see the private state, not
the public state.

Most of the patch is getting a test that will actually reproduce the
error. Only the test `test_python_os_plugin_remote` actually reproduced
the error. In `test_python_os_plugin` we actually do start up the
private state thread before handling the event. `test_python_os_plugin`
is there for completeness sake.

It's not necessary on posix platforms as of #126935 and it's ignored on
windows as of #138896. For both platforms, we have a better way of
inheriting FDs/HANDLEs.

This patch should be mostly obvious, but in one place, this patch
changes:

  const auto &it = std::find(...)

to:

  auto it = llvm::find(...)

We do not need to bind to a temporary with const ref.

This is always on, and has been since at least 2011 from what I can
tell. The code in the `#else` clauses are effectively dead code.

This macro does not do what is described. The only thing it actually
does control is whether or not the process's memory cache gets flushed
when writing to an address. It does not override the setting
`target.process.disable-memory-cache`.

Instead of making it work as intended, I chose to remove the macro. I
don't see much value in being able to override the setting with a
preprocessor macro.

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.

Follow-up to #138892 fixing breakage on windows. Calling
ClearAllLoadedSections earlier is necessary to avoid throwing out the
work done by the windows process plugin.