ByteQ now has ReadSlice(...) and WriteSlice(...)

ByteQ.ReadSlice(buffer []byte) bool, will fill buffer with bytes from
the underlying ringbuffer. It either reads enough bytes to completely
fill buffer, and returns true, or it reads no bytes at all, and returns
false.

ByteQ.WriteSlice(buffer []byte) bool, will write bytes from buffer to
the underlying ringbuffer. It either writes all bytes in buffer,
and returns true, or it writes no bytes at all, and returns false.

These methods are provided as a more user friendly way to read and write
using ByteQ. The most significant improvement is the fact that we can
now write or read an arbitrary []byte buffer in one call. With existing
methods partial reads/writes are possible and must be programmed for.
*Buffer/Commit* changed to Acquire*/Release*

Previously a queue such as ByteQ would have a pair of methods for
performing a read. ByteQ.ReadBuffer(...) would return a buffer full of
readable bytes. ByteQ.CommitRead() would indicate that the read had
completed. Similarly we had ByteQ.WriteBuffer(...) and
ByteQ.CommitWrite()

These methods are now named

ByteQ.AcquireRead(...)
ByteQ.ReleaseRead()

ByteQ.AcquireWrite(...)
ByteQ.ReleaseWrite()

PointerQ follows the same convention.
ByteQ.ReadSlice()/WriteSlice() -> Read()/Write()

In an effort to simplify the queue interfaces. The simple method names
also indicate that a user should expect this to be the simplest way to
read and write from the queue.
PointerQ now has Read() and Write() methods

PointerQ.Read(buffer []unsafe.Pointer) bool, will fill buffer with
pointers from the underlying ringbuffer. It either reads enough pointers
to completely fill buffer, and returns true, or it reads no pointers at
all, and returns false.

PointerQ.Write(buffer []unsafe.Pointer) bool, will write pointers from
buffer to the underlying ringbuffer. It either writes all pointers in
buffer, and returns true, or it writes no pointers at all, and returns
false.
Added an interface for each queue type

The interfaces are intended primarily as succinct documentation for each
queue. Because of the extensive delegation of methods down to commonQ it
was not obvious which methods were provided by each queue. Now this
information can be easily understood by reading the interface.

No performance tests use the interfaces, they use raw structs directly.
Single pointer perf test moved to pointersingle.go

Previously the performance test would (secretly) run the pointer queue
performance test using the Write/ReadSingle(...) methods if the
-batchSize value was 1, which was the default value.

The new PointerQ performance tests are

-pq
	Runs PointerQ
-pqsingle
	Runs PointerQ reading and writing a pointer at a time
-pqsinglel
	Runs PointerQ lazily reading and writing a pointer at a time
-pqs
	Runs PointerQ using whole buffer copying
-pql
	Runs PointerQ with lazy writes

This feels like too many. It would be great to be able to reduce this.
Rewrite of all flags for perf tests

Convention used is now <queue-type><method-type>[lazy]

Queue types:

  pq  - PointerQ
  bq  - ByteQ
  bcq - ByteChunkQ

Method Types:

  rw - Read/Write
  ar - Acquire/Release
  s  - ReadSingle/WriteSingle

If the flag ends in 'l' the lazy methods are used

For example

  -bqar  - "Runs ByteQ using Acquire/Release methods"
  -bqarl - "Runs ByteQ with lazy Acquire/Release methods"
  -pqs   - "Runs PointerQ reading and writing a pointer at a time"

As an additional note we now have 10 different performance tests
(ingoring) parameters like qSize and batchSize. This is too many,
performance regressions very likely to go unnoticed. We really need an
automated performance test suite to spot regressions or a reduced
testing surface area. I like both, and like the second option the most.