WIP -- Parallelize GFDL TC detector using OpenMP

[burlen]

this is easy to do and will speed things up when the candidate stage is called on a single time step. But this will have to be used with care since it would potentially conflict with our typical use of thread pools. We might make this the default and then override in our apps that use thread pools so that Python users would get parallel code when processing a single time step.

We'll have to add an addition table_sort to our regression tests since the candidates are no longer generated in a deterministic order.

Would be nice to automate OpenMP settings. I've made an initial pass at this. It would be better to use MPI to coordinate the assignment of threads to core across ranks on the node. We do this for our thread pools. I'm not sure we can make use of MPI in the library constructor , which is where we have to put OpenMP settings.

initial results are positive, this is a Debug build

[burlen]

use on perlmutter, schedule 1 rank per socket.

OMP_DISPLAY_AFFINITY=true OMP_PROC_BIND=true  OMP_PLACES=cores TECA_DO_TEST=0 time srun -n 2 --cpu-bind=verbose ./bin/test/test_tc_candidates /pscratch/sd/l/loring/teca_testing/cam5_tc_data/cam5_1_amip_run2_cam2_h2_1990-07-01-10800'\.nc$' test_tc_candidates_20.bin "0" "3" "1" 32 "U850" "V850" "UBOT" "VBOT" "PSL" "T500" "T200" "Z1000" "Z200" "-50" "50" 6

[burlen]

1 MPI rank, from 1 to 127 threads