Worker threads = (P?) cores

[ProgramMax]

Currently, the worker thread number is hard-coded.
This should likely relate to either the total number of threads or the expected workload (for example, if something can be handled in parallel or not).

For this test program, perhaps total number of threads is the way to go. But we should measure and confirm that. Perhaps there is diminishing returns or scheduling contention.

Additionally, should we attempt to only schedule on P-cores? This also might relate to the workload.

It is likely we'll need to add support for all of this, whether we use it or not. It could be moved to a separate program just to confirm assumptions. That would allow us to be alerted if the OS behavior changes, for example.

[ProgramMax]

This is partly implemented by #4 , which now finds how many actual cores the processor has (and notes how many hyperthreaded cores are available).
However, it doesn't yet check for performance vs efficiency cores.

Windows doesn't specifically report P-core and E-core. Rather, it assigns each core a number 0-255 to indicate performance.
This makes room for things like ARM's big.Medium.LITTLE, where there are more than 2 profiles.