This uses [teyit](https://pypi.org/project/teyit/) to modernize asserts,
as recommended by the [unittest release
notes](https://docs.python.org/3.12/whatsnew/3.12.html#id3).

For example, `assertTrue(a == b)` is replaced with `assertEqual(a, b)`.
This produces better error messages, e.g. `error: unexpectedly found 1
and 2 to be different` instead of `error: False`.

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

that pushes a step over plan.  Relax the listing checker
so it will look past any entries after the ones listed in
the input patterns.  Then for the internal plans just check
for the StepOver plan that our scripted plan pushes, and look past
any others.

This should make the test more robust on systems that don't use the
step-in then push a step-out plan to step over a function.

The test works fine on x86-linux.

Mark it expected fail for now.

The test output shows that the "internal" thread listing isn't showing the
step out plan that we use to step back out of a function we're stepping into.
The internal plan listing code has nothing platform specific in it, so that
isn't the problem.

I am pretty sure the difference is that on MacOS we step into the function and then need to
step back out again so we push the internal plan the test is checking for.  But on Linux we
are able to step past the function without stepping into it.

So nothing is actually going wrong here, I just need to find a better test case where I
can ensure we are going to have to push a private plan.  It's probably better to test this
using a custom thread plan, then I can control the state of the plan stack better.

That's for Monday...

capture the test stdout, so put the info I need to see in the error
message instead.

Also turn on the command trace unconditionally for TestThreadPlanCommands.py as the
tests for the Ubuntu bot don't seem to run with -t making it hard to see why this is
failing remotely.