Add `stop_description` as a Python convenience property to `SBThread`.

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.

When OS plugins are present, it can be helpful to query information
about the backing thread behind an OS thread, if it exists. There is no
mechanism to do so prior to this commit.

As a first step, this commit enhances `thread info` with a
`--backing-thread` flag, causing the command to use the backing thread
of the selected thread, if it exists.

These prevented ThreadMemory from correctly returning the
Name/Queue/Info of the backing thread.

Note about testing: this test only finds regressions if the system sets
a name or queue for the backing thread. While this may not be true
everywhere, it still provides coverage in some systems, e.g. in Apple
platforms.

Currently, an LLDB target option controls whether plugins report all
threads. However, it seems natural for this knowledge could come from
the plugin itself. To support this, this commits adds a virtual method
to the plugin base class, making the Python OS query the target option
to preserve existing behavior.

In the presence of OS plugins, StopInfoMachException currently
propagates breakpoint stop reasons even if those breakpoints were not
intended for a specific thread, effectively removing our ability to set
thread-specific breakpoints.

This was originally added in [1], but the motivation provided in the
comment does not seem strong enough to remove the ability to set
thread-specific breakpoints. The only way to break thread specific
breakpoints would be if a user set such a breakpoint and _then_ loaded
an OS plugin, a scenario which we would likely not want to support.

[1]:
https://github.com/swiftlang/llvm-project/commit/ab745c2ad865c07f3905482fd071ef36c024713a#diff-8ec6e41b1dffa7ac4b5841aae24d66442ef7ebc62c8618f89354d84594f91050R501

This fixes a regression caused by my commit where I added test
as skipped using a decorator but forgot to add import decorator
in TestPythonOSPlugin.py

test_run_python_os_step in TestPythonOSPlugin.py fails on Windows
after PR #97043. The test passes when run individually using dotest.py.

I have marked this skipped for windows to make LLDB AArch64 Windows
buildbot happy.

https://github.com/llvm/llvm-project/commit/a4c18137d84bc48df49ee0101bef465a955e62ac
https://lab.llvm.org/buildbot/#/builders/141/builds/379

In one of my recent PRs I mistakenly had two test-cases with the same
name, preventing one of them to run. Since it's an easy mistake to make
(e.g., copy pasting existing test-cases), I ran following sanity-check
script over `lldb/test/API`, which found couple of tests which were
losing coverage because of this (or in some cases simply had duplicate
tests):
```
import ast
import sys

filename = sys.argv[1]
print(f'Checking {filename}...')
tree = ast.parse(open(filename, 'r').read())

for node in ast.walk(tree):
    if not isinstance(node, ast.ClassDef):
        continue

    func_names = []
    for child in ast.iter_child_nodes(node):
        if isinstance(child, ast.FunctionDef):
            func_names.append(child.name)

    seen_func_names = set()
    duplicate_func_names = []
    for name in func_names:
        if name in seen_func_names:
            duplicate_func_names.append(name)
        else:
            seen_func_names.add(name)

    if len(duplicate_func_names) != 0:
        print(f'Multiple func names found:\n\t{duplicate_func_names}\n\tclass {node.name}\n\tfile: {filename}')
```

This patch fixes these cases.

assertEquals is a deprecated alias for assertEqual and has been removed
in Python 3.12. This wasn't an issue previously because we used a
vendored version of the unittest module. Now that we use the built-in
version this gets updated together with the Python version used to run
the test suite.