Benchmark reads while a writer is committing

[venkat1701]

Closes #33

Adds a 10-second mixed workload:

• mixed.read: every thread but one does single incidence lookups in a closed loop.
• mixed.write: the last thread commits 10 updates at a time on a fixed schedule of 1,000 updates/s.

Writer latency is measured from each commit's scheduled start, so a stall shows up in the commits queued behind it instead of quietly slowing the writer. The writer stops at the deadline even if it's behind, so a store that can't keep up shows a lower achieved rate.

Readers run millions of operations, so each thread keeps a uniform random sample of 200,000 latencies plus the exact max (Reservoir). The writer gets bytes written, and the readers get allocation and GC, like the other workloads. Both results depend on timing, so the report shows n/a under Results agree; any result can now say checked: false.

My first try used 100-update commits at 2,000 updates/s. Neither store kept up on this loaded machine, so the latency mostly measured a growing backlog, and there were too few commits for a useful p99.9. 10 at 1,000/s gives about 1,000 commit samples and is well within what both stores can do alone.

Smoke run at scale 1, async, 9 readers, machine load around 20:

	HStore	HyperGraphDB
reads/s	539,927	256,318
read p99	35 µs	329 µs
read max	752 ms	111 ms
updates/s achieved (target 1,000)	738	1,000
commit p50, from schedule	2.17 s	38 ms
GC pause during the run	1.37 s	0.26 s

So HStore readers are faster and steadier at p99, but its writer can't keep the schedule while they run. Together with latency.commit (#37) and the 20 KiB written per small commit (#38), this points at the cost of small commits. I'll open an issue for that with a profile.