Update CPU topology initialization (Fixes subsequent hang in CmiBarrier)

[minitu]

A hang could be observed when CmiBarrier is used after CmiInitCPUTopology in _initCharm (src/ck-core/init.C). This issue was caused by comm threads prematurely exiting the CmiNetworkProgress loop (lines 485-490) and thus failing to pass the CmiReduce message (line 538) to PE 0.

I believe the original code seemed to work fine (when CmiBarrier was not used) because at some later point in time the comm threads would have resumed processing their message queues, including the remaining CmiReduce messages.

This PR modifies the CPU topology init process (how messages are passed, in particular), by referring to the CPU affinity init code which did not exhibit issues with subsequent CmiBarrier calls.

[minitu]

The hang can be observed with comm thread builds (e.g. UCX), with a CmiBarrier placed after CPU topology init.
Test program: hello/1darray
On LLNL Lassen: jsrun -n2 -a1 -c2 -K1 -r2 ./hello +ppn 1 +setcpuaffinity

[minitu]

Removing from 6.11 for now, as it is unclear how this should be fixed.

[minitu]

Closing, will reopen or create a new PR once we figure out how to solve the CmiBarrier hang.