Added unit tests for spscq.commonQ

commonQ.AcquireWrite(...)/commonQ.ReleaseWrite() advances write field

commonQ.AcquireRead(...)/commonQ.ReleaseRead() advances read field

commonQ.AcquireWrite(...)/commonQ.ReleaseWrite() does not allow write to
wrap past read

commonQ.AcquireWrite(...)/commonQ.ReleaseWrite() does not allow read to
overtake write
sqscq.newCommonQ(...) returns an error

Previously if the size argument was not a power of two newCommonQ(...)
would panic. This is not good form and an error is now returned instead.
spscq.newCommonQ(...) errors when size > 2^42

newCommonQ(...) now has a size limit enforced. No queue may be created
with size greater than 2^42. If the underlying ring-buffer is storing
bytes a 4,096 gigabyte ring-buffer can be created, which is enough for
most applications.

We chose this limit because we found that including powers of two up to
2^63 broke our tests. The tests assume that they are able to increment
the write/read indices past the size value. When size is large the
write/read indices will overflow causing tests to fail.

The solution is to impose a reasonable limit on size in the tests, but
it would seem unwise to allow users to construct instances of commonQ we
were explicitly unwilling to test, so the limit is imposed in the
newCommonQ(int64) constructor function.

The, perhaps conservative, limit of 2^42 can be raised in the future
without breaking backwards compatibility.
Added fmath.Max(int64,int64) int64

Including tests which similar to the fmath.Min(...) function.

The limits to the size of the random numbers generated has been increased
to 2^42. This is the same as the current limit on the size of ring-buffers
used in the queue/spscq packages. These limits are not necessary and the
tests should be expanded to cover a wider range of integer values.
Added String() method to spscq.commonQ

Useful for make test failures human readable.
Replaced commonQ tests with invariant tests

Previously we had a number of tests ensuring that specific properties
are maintained for a particular field, such as write or read. These have
been replaced with a collection of tests which compare the state change
that occurred with a method call.

Currently we have state change tests for the
AcquireWrite/ReleaseWrite/Lazy and AcquireRead/ReleaseRead/Lazy methods.
Adding ftime package

This package contains three functions.

Counter() returns integer values which are guaranteed to increase
monotonically across calls on the same CPU core. Counter() is intended
to be used as a fine resolution performance measurement tool. The value
returned by Counter() need not correspond to a particular unit of time,
e.g. nanoseconds. It is more common for the value to reflect completed
CPU clock cycles.

If IsCounterSteady() returns true then we guarantee that values returned
by Counter() increase at a uniform 'steady' rate, independent of the
clockrate of the CPU it is running on.

If IsCounterSMPMonotonic() returns true we guarantee that for two calls
to Counter(), A and B, where A 'happens before' A, the value of B will
always be greater than A, even if those two calls are on separate cores
on the same socket. We make no guarantees across CPU sockets.
sqscq.commonQ tests for three scenarios

Even write, even read
Where we write then read the same amount.

Light write, heavy read
Where we write then read twice that amount.

Heavy write, light read
Where we write then read half that amount.
Now identifying TSC_Invariant in the edx register

Previously we were looking for it in the ecx register, where it does not
live.