[lldb][API test] TestRunLocker is flakey, fix (#203429)

TestRunLocker is intended to confirm that certain SB API commands behave
correctly while the inferior process is running. It has two modes - one
where it launches the process stopped, and then resumes it, and another
where it simply launches it. Both are intended to wait until the process
is eStateRunning, and then do the test commands including a
HandleCommand that refers to `lldb.target`.

This test is flakey on Linux and macOS because `lldb.target` comes back
as a None type very early in process setup. We weren't actually running
the "launch to the first instruction, then resume the process" codepath
that this test was written to have - I fixed that last week. But we
still see flakey behavior.

I thought the flakiness might be the private stops we are doing as we're
notified about binaries being loaded in the process, stepping past the
breakpoint in the dynamic loader, and then resume. I tested this theory
by changing the inferior program to be a tight infinite loop, then
putting a breakpoint with a very high skip count, so lldb was forced to
do many private stop/resumes. I changed the test case to launch to
main(), then start hitting these infinite private stop/resumes and doing
the test commands. The test commands work fine in this case.

It's something unique about the early process startup that is triggering
the flakey failures. On the one hand, there is something wrong here,
where `lldb.target` will return None when we are doing commands while
executing very early in startup. But that wasn't what this test was
intended to exercise, and most importantly, it doesn't work consistently
so hammering on this in a test case is just making our CI less reliable.

I removed the "launch to first instruction, then resume" codepath and
have TestRunLocker run to a breakpoint on main() - where we've done all
our process setup and binary loading - then resume the process and test
our commands while the inferior is in eStateRunning. It doens't fail any
more on my macOS desktop.

I also removed a Skip for aarch64 linux which said it was flakey. I
expect that's the same flakiness that's hitting all the other CI too.

GitOrigin-RevId: fe60500615bb05a20d1fe031b62ccf7da1e247cc