Increased performance by 30% for RGBA and 45% for Gray images, minor
performance increase for 16-bit images.

The start offset calculated by createWeights are stored in a slice and
passed to the resize functions to prevent duplication of effort.

This is a complete rewrite! The tight scaling loop needs data locality for optimal performance. The old version used lots of pointer redirections to access image data which was bad for data locality. By providing the complete loop for each image type, this problem is solved. Unfortunately this increases code duplication but the result should be worth it: I could measure a ~6x speed-up for certain test cases!

Caching kernel weights makes using the LUT based approach obsolete. Now they seem to be even slower than their counterparts.

For each row the convolution kernel is evaluated at fixed positions around "u". By calculating these values once for each row, a huge speedup is achieved.

Run "go test -bench LargeJpegThumb" to benchmark all functions at once.

Should be ~5x faster! More optimization will follow.

before:
> go test -bench .
PASS
Benchmark_BigResizeLanczos3-4	       1	2438137093 ns/op
Benchmark_BigResizeLanczos3Lut-4	       1	1157612362 ns/op
Benchmark_Reduction-4	       2	 743950618 ns/op

after:
> go test -bench .
PASS
Benchmark_BigResizeLanczos3-4	       5	 403685685 ns/op
Benchmark_BigResizeLanczos3Lut-4	      10	 225539497 ns/op
Benchmark_Reduction-4	      10	 207004759 ns/op

Profiling the resize operation using Lanczos kernels showed that most of
the time was spent in the Sin function, which is called twice per
evaluation of the Lanczos kernel. Generating a lookup table and doing a
linear interpolation between table entries speeds up the resize by a
factor of 4.

This also fixes a quality issue with Mitchell-Netravali: A factor was
missing in the calculation.

Describe filterModel interface,
Extract bool-to-int method