Work in progress: The timer thread should not be a Python thread.

This works as follows:

• Spins up a thread to update a global "now" variable from the system monotonic clock every ~10μs.
• On entry to each recorded function, grab "now" from global variable and push it to timer stack
• On exit from recorded function, grab "now" from global variable and increment named time by the time delta.

Calling the system monotonic clock for each event is too expensive and distorts the results.

Some care is needed to get this to work properly. Specifically, the machine needs to have spare cores, so that timer thread runs on a different CPU core from the timed program. The timed program needs to be single-threaded.
When benchmarking, we expect both of these to be true.

Provided that those two requirements are met, this approach has low-overhead (a few memory accesses and sometimes a cache miss to fetch "now") and high precision ("now" is updated every ~10μs).

Example output:

$ rm /tmp/py_timings/* ; ./python -c "pass" ; python3 Tools/scripts/sum_timers.py

dealloc: 468.0 μs 5.9%
eval: 2.2 ms 27.4%
free: 152.0 μs 1.9%
gc: 1.2 ms 15.1%
import_: 65.0 μs 0.8%
main: 1.4 ms 17.6%
malloc: 632.0 μs 7.9%
native: 1.9 ms 23.5%

$ rm /tmp/py_timings/* ; time ./python -m test ; python3 Tools/scripts/sum_timers.py

...
dealloc: 14.4 secs 0.7%
eval: 489.3 secs 24.1%
free: 5.8 secs 0.3%
gc: 395.1 secs 19.4%
import_: 838.1 ms 0.0%
main: 3.1 secs 0.2%
malloc: 8.7 secs 0.4%
native: 1115.0 secs 54.9%