Re-investigate parallel_map default number of CPU strategy

[mtreinish]

What should we add?

Right now the default number of CPUs used with parallel_map is the number of physical CPUs available:

qiskit/qiskit/tools/parallel.py

Line 97 in 01bb111

CPU_COUNT = CONFIG.get("num_process", local_hardware_info()["cpus"])

which is pulled from psutil here:

qiskit/qiskit/utils/multiprocessing.py

Line 36 in 01bb111

"cpus": psutil.cpu_count(logical=False) or 1,

This was done at the time because benchmarking showed that there was minimal if any improvement from running parallel processes on logical cores (i.e. SMT or hyperthreading cores). However, this code was introduced ~5 years ago (see: #701), we should check that this assumption is still true on more modern hardware. We should check this on various CPU types and also different OSes (also remembering multiprocessing is disabled by default on macOS and windows, so it will need to be explicitly re-enabled to test this).

[jakelishman]

As part of this, it would be useful to have a less hacky way to force parallelisation in parallel_map, if not only for our own testing purposes. It seems quite likely at the moment that the internal dispatch logic is resistant to the attempts to override qiskit.tools.parallel.PARALLEL_DEFAULT in the CI suite, and (at least) macOS Azure jobs intended to test transpiler parallelism aren't actually running in parallel contexts.