Remove batching on unittest thread, use historical data to inform batching

[weswigham]

This should help guarantee that the unittest thread is not unintentionally on the critical path of completion time - in my case, this improved test duration by 8 seconds - 126 seconds down to 118 seconds. This may help with perf issues you were seeing, @andy-ms ?

[weswigham]

@andy-ms I've also now added a feature where the data for the runtime of prior test runs is used to inform the packing of batches for future sort runs. The historical data also reduces test discovery time by 1/3rd of a second by avoiding all of the stat calls, which is somewhat nice. I have not witnessed more than a second of difference in the end times of worker threads (and no more than 2 or 3 seconds on the size-informed runs); so at this point, any remaining differences in completion time would have to be harness overhead (or additional runtime caused by the addition of more tests).

As an added bonus; new tests will be run first if perf data from a prior run is available, so you can get feedback from your changes more rapidly.

[ghost]

Merge conflict 👇

[weswigham]

@andy-ms rebased and resolved.

[sandersn]

typo:detected

[ghost]

This doesn't seem to have changed the time for me. I measured 2min 45s, compared to 2min 48s in #18462 and 2min 24s before any of this. @weswigham Could you run a comparison between c522f37 and d1c4754 on your machine?