This has been bugging me for a bit.  The concurrent.futures Executor
requires checking the result for the error to be raised.  That makes
sense, but just means we need to consume the result explicitly here
to ensure we know about compile errors.

Otherwise, compile errors just pass silently (which is very confusing
if the old object files are still around and the tests run based on
the old version).

Use `concurrent.futures.ThreadPoolExecutor` in distutils
instead of `multiprocessing.pool.ThreadPool`.

Fix #21026

Added ARM compiler.

  this patch is really important since most of the users aren't able to determine
  the build error when the toolchain or the built environment missing
  executable files of compiler, linker, assembler, etc.

This is just a technical prototype to measure and discuss the impact and
implication of moving to C++ for kernel code generation.

Apparently, there is a second `compiler_so` that is actually the
main compiler being used, and modifying only the first one is just
futile.

The old try was `-ffp-exception-behavior=strict`, but that seems to
be a fairly new addition (and doesn't even work on MacOS with 10.0)

`-ftrapping-math` seems to be the older, equivalent option.

This also affects all users of numpy distutils

Threading is guaranteed to be supported in Python 3.7+