libtest: Use deterministic HashMap, avoid spawning thread if there is no concurrency
It seems desirable to make a test and bench runner deterministic, which this achieves by using a deterministic hasher. Also, we we only have 1 thread, we don't bother spawning one and just use the main thread.
The motivation for this is to be able to run the test harness in miri, where we can neither access the OS RNG, nor spawn threads.
Add option to run all tests
This adds the "--include-ignored" flag to libtest, which allows running ignored and unignored tests in one go.
Closes#50363
libtest terse format: show how far in we are
So for example `./x.py test src/libcore` looks like
```
running 881 tests
.................................................................................................... 100/881
.................................................................................................... 200/881
.................................................................................................... 300/881
.............................................................i.i.................................... 400/881
.................................................................................................... 500/881
.................................................................................................... 600/881
.................................................................................................... 700/881
.................................................................................................... 800/881
.................................................................................
test result: ok. 879 passed; 0 failed; 2 ignored; 0 measured; 0 filtered out
```
When I am waiting for 3500 ui tests to complete, I am often missing some sense of how far in these 3500 it is.
Getting the total count in `write_run_start` is a bit hacky; I did that to not change the "public interface" of the formatters. I can also give them an extra argument in their constructor so that they know from the beginning how many tests there will be. Would you prefer that? (I think I would, but I wanted to get feedback first.)
improve diagnostics for tests with custom return values
This is an attempt at getting the ball rolling to improve the diagnostics for test functions that return custom `impl Termination` values (see #52436).
An alternative could be to use `eprintln!`, but including this in the panic message felt nicely consistent with how failing test assertions would be reported.
Let me know what you think!
Don't format!() string literals
Prefer `to_string()` to `format!()` take 2, this time targetting string literals. In some cases (`&format!("...")` -> `"..."`) also removes allocations. Occurences of `format!("")` are changed to `String::new()`.
Jethro Beekman