Add multithreaded performance test

Since the way spdr is implemented right now relies on a single
allocator shared amongst all threads, I expect to see a high
overhead when concurrent cores are attempting to trace at high
frequency.

perf-test.c is designed to show this.
rearranging memory layout of struct spdr

It improves performance, this shows the writes to blocks_next cause
unecessary load between all threads.

It also improves performance because tracing_p reads would be affected
by writes to blocks_next.

Using Instruments on Mac with the MACHINE_CLEAR.MEMORY_ORDER[1]
counter	shows an improvement.

[1] "Execution pipeline restart due to Memory ordering conflicts"
perf test: allow comparison of multiple sdpr / global spdr
reduce cache line sharing protection buffer
build event on the stack then record

Build the event on the stack before recording it to the log,
so that we can later make sure the calls to the clocks are
made with maximum use of the cache.

This requires us to not allocate the clock together with the events,
so that we do not confuse memory that is often read from memory
that is often written.
improve cache locality by having clock close in read arena

Clock lookups were slow because we had the clock in the event arena,
in close quarters with the writable data. Pulling it out in the read
section reduces overhead when occupying multiple cores.

A further optimization would be to not having to read anything. This
would be accomplished by storing opaque timestamps and doing the
conversion to microseconds at reporting time only.
fixup! improve cache locality by having clock close in read arena
fix source list for win32
fixup! build event on the stack then record
minor reshuffling
fixup! build event on the stack then record
remove some conditionals when looking up args