Typo fix
Use int32 rather than float32 for synthetic tests

This avoids rounding errors I was experiencing when adding up lots of
float32s in different orders (see parallel benchmarks to be committed).
Add two more slice-based synthetic approaches

Slices are nicer than arrays -- and in particular, using this approach
would let us implement an expanding table in the future.

The current benchmarks are showing that with a couple of exceptions,
all the synthetic approaches are neck-and-neck. The exceptions are:

- SliceOfSlice: this is slow because it uses unnecessary indirection
- FilterFn: function calls are quite expensive in the inner loop

BenchmarkSumArrayMatrix             2000            846165 ns/op
BenchmarkSumOneRolledLoop           2000            934485 ns/op
BenchmarkSumOneUnrolledLoop         2000            914220 ns/op
BenchmarkContiguousSliceMatrix      2000            847067 ns/op
BenchmarkContiguousSliceByteMatrix  2000            850029 ns/op
BenchmarkSumSliceOfSliceMatrix      2000           1121611 ns/op
BenchmarkSumByteMatrix              2000            840480 ns/op
BenchmarkSumUsingFilterFn           1000           1620425 ns/op
BenchmarkSumUsingInlineFilterFn     2000            996601 ns/op
Parallel benchmarks

Scanning the table in chunks can have a big effect. However, it
depends on several factors. If the row size is huge, then we become
more and more limited by memory bandwidth. The relative capabilities
of the CPU and memory matter a lot.

However, at least for the synthetic benchmarks, increasing the
parallelism appears to always help; sometimes a lot.

Here are two sets of benchmarks. First, here's my 3-year-old i5-2500k
with fairly slow memory:

BenchmarkParallelMatrix8Col1Thread-8        5000            343732 ns/op
BenchmarkParallelMatrix8Col2Threads-8      10000            269222 ns/op
BenchmarkParallelMatrix8Col4Threads-8       5000            285426 ns/op
BenchmarkParallelMatrix8Col8Threads-8      10000            290470 ns/op
BenchmarkParallelMatrix128Col1Thread-8      2000           1302064 ns/op
BenchmarkParallelMatrix128Col2Threads-8     2000           1134004 ns/op
BenchmarkParallelMatrix128Col4Threads-8     2000           1238226 ns/op
BenchmarkParallelMatrix128Col8Threads-8     2000           1229033 ns/op

Now here's a super-beefy c3-8xl EC2 instance:

BenchmarkParallelMatrix8Col1Thread-8       10000            212128 ns/op
BenchmarkParallelMatrix8Col2Threads-8      10000            119392 ns/op
BenchmarkParallelMatrix8Col4Threads-8      20000             98692 ns/op
BenchmarkParallelMatrix8Col8Threads-8      20000             87084 ns/op
BenchmarkParallelMatrix128Col1Thread-8      1000           1655424 ns/op
BenchmarkParallelMatrix128Col2Threads-8     2000            985387 ns/op
BenchmarkParallelMatrix128Col4Threads-8     5000            575926 ns/op
BenchmarkParallelMatrix128Col8Threads-8     5000            517407 ns/op