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.

This is an ongoing series of commits that are reformatting our Python
code. Reformatting is done with `black` (23.1.0).

If you end up having problems merging this commit because you have made
changes to a python file, the best way to handle that is to run `git
checkout --ours <yourfile>` and then reformat it with black.

RFC: https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style

Differential revision: https://reviews.llvm.org/D151460

Eliminate boilerplate of having each test manually assign to `mydir` by calling
`compute_mydir` in lldbtest.py.

Differential Revision: https://reviews.llvm.org/D128077

Fixes #19721
Fixes #18440
Partially fixes bug #47660
Fixes #47761
Fixes #47763

Sponsored by: The FreeBSD Foundation

lldb reports (and lldbutil.continue_to_breakpoint returns) a stop reason
even for suspended threads. Fix the test to expect that.

This was making the test flaky, as most of the time, the two threads
stop simultaneously, and the synchronization code is not executed.

One of the tests in this test setup was copied from a more complex test, and I didn't know
if the setup or the subsequent parts of the test were the ones that fail on Linux.  Looks
like it was the latter, so let's mark this succeeding.

This way if you have a long stack, you can issue "thread backtrace --count 10"
and then subsequent <Return>-s will page you through the stack.

This took a little more effort than just adding the repeat command, since
the GetRepeatCommand API was returning a "const char *".  That meant the command
had to keep the repeat string alive, which is inconvenient.  The original
API returned either a nullptr, or a const char *, so I changed the private API to
return an llvm::Optional<std::string>.  Most of the patch is propagating that change.

Also, there was a little thinko in fetching the repeat command.  We don't
fetch repeat commands for commands that aren't being added to history, which
is in general reasonable.  And we don't add repeat commands to the history -
also reasonable.  But we do want the repeat command to be able to generate
the NEXT repeat command.  So I adjusted the logic in HandleCommand to work
that way.

Differential Revision: https://reviews.llvm.org/D119046