more reasonable performance test, with comparable outputs

We want to be able to compare multithreaded and single threaded outputs.
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"
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.
fix source list for win32
minor reshuffling
remove some conditionals when looking up args
group blocks into buckets (right now only one)
align arena to 64 bytes to reduce variance
prepare implementation of multiple parallel buckets
dispatch traces to 8 different buckets to reduce sharing

In order to remove false sharing between concurrent threads,
we dispatch each trace to a randomly assigned bucket. This
reduce sharing reads on the cache line holding the linear
allocator between different cores.