armv6: Add nearest-scaled-cover src_0565_0565 fast path

This is adapted from the nearest scaled cover scanline fetcher, modified to
pack output data in 16-bit units.

lowlevel-blt-bench -n src_0565_0565:

     Before          After
     Mean   StdDev   Mean   StdDev  Confidence  Change
L1   119.6  4.1      72.5   1.1     100.0%      -39.4%
L2   45.2   1.4      55.4   2.0     100.0%      +22.5%
M    47.1   0.1      71.3   0.1     100.0%      +51.4%
HT   26.4   0.2      31.8   0.3     100.0%      +20.3%
VT   25.0   0.2      30.0   0.3     100.0%      +20.3%
R    22.6   0.2      27.6   0.2     100.0%      +22.0%
RT   9.7    0.2      10.3   0.2     100.0%      +5.6%

affine-bench * 0 0 1 src r5g6b5 r5g6b5:

     Before          After
     Mean   StdDev   Mean   StdDev  Confidence  Change
0.5  59.6   0.1      129.6  0.1     100.0%      +117.2%
0.75 52.0   0.1      106.3  0.1     100.0%      +104.6%
1.0  47.2   0.1      71.7   0.0     100.0%      +52.0%
1.5  39.1   0.1      68.1   0.1     100.0%      +74.2%
2.0  37.7   0.1      68.7   0.1     100.0%      +82.2%
armv6: Add four more nearest-scaled-cover fast paths

These complete the set of fast paths where currently pixman-fast-path.c
provides versions that get selected in preference to the armv6-optimised
scanline fetchers/combiners/writeback routines.

Because generation of these fast paths is macroised, the patch required
to add them is fairly simple.

lowlevel-blt-bench -n over_8888_8888:

     Before          After
     Mean   StdDev   Mean   StdDev  Confidence  Change
L1   13.8   0.0      26.5   0.2     100.0%      +91.7%
L2   9.4    0.2      22.9   0.4     100.0%      +142.6%
M    8.6    0.0      23.8   0.0     100.0%      +176.1%
HT   7.4    0.0      14.1   0.1     100.0%      +91.2%
VT   7.3    0.0      13.4   0.1     100.0%      +84.1%
R    7.0    0.0      13.0   0.1     100.0%      +85.9%
RT   4.5    0.1      6.2    0.1     100.0%      +36.6%

affine-bench * 0 0 1 over a8r8g8b8 a8r8g8b8:

     Before          After
     Mean   StdDev   Mean   StdDev  Confidence  Change
0.5  9.4    0.0      28.0   0.0     100.0%      +197.4%
0.75 9.0    0.0      26.1   0.0     100.0%      +190.2%
1.0  8.6    0.0      24.4   0.0     100.0%      +184.6%
1.5  7.9    0.0      21.7   0.0     100.0%      +173.4%
2.0  7.3    0.0      19.6   0.0     100.0%      +166.6%

lowlevel-blt-bench -n src_x888_8888:

     Before          After
     Mean   StdDev   Mean   StdDev  Confidence  Change
L1   108.6  2.0      66.3   0.9     100.0%      -39.0%
L2   32.4   1.5      44.3   2.1     100.0%      +36.8%
M    27.5   0.1      62.0   0.1     100.0%      +125.6%
HT   20.3   0.1      28.7   0.2     100.0%      +41.2%
VT   19.9   0.1      26.7   0.1     100.0%      +34.4%
R    18.6   0.1      25.3   0.2     100.0%      +36.3%
RT   8.7    0.1      9.8    0.2     100.0%      +12.6%

affine-bench * 0 0 1 src x8r8g8b8 a8r8g8b8:

     Before          After
     Mean   StdDev   Mean   StdDev  Confidence  Change
0.5  45.2   0.0      97.2   0.1     100.0%      +115.1%
0.75 35.9   0.1      76.7   0.1     100.0%      +113.9%
1.0  29.6   0.1      61.1   0.1     100.0%      +106.4%
1.5  21.4   0.0      52.7   0.1     100.0%      +145.9%
2.0  16.7   0.0      43.0   0.1     100.0%      +156.9%

lowlevel-blt-bench -n src_8888_0565:

     Before          After
     Mean   StdDev   Mean   StdDev  Confidence  Change
L1   57.2   0.7      43.1   0.4     100.0%      -24.7%
L2   23.0   1.0      32.8   1.0     100.0%      +42.5%
M    24.8   0.0      42.2   0.0     100.0%      +70.0%
HT   18.0   0.1      22.1   0.1     100.0%      +22.5%
VT   17.1   0.1      21.0   0.1     100.0%      +22.5%
R    16.5   0.1      20.0   0.1     100.0%      +21.4%
RT   8.3    0.2      8.4    0.1     95.0%       +1.0%  (insignificant)

affine-bench * 0 0 1 src a8r8g8b8 r5g6b5:

     Before          After
     Mean   StdDev   Mean   StdDev  Confidence  Change
0.5  34.9   0.0      55.3   0.0     100.0%      +58.7%
0.75 29.3   0.0      49.1   0.0     100.0%      +67.4%
1.0  24.8   0.0      42.6   0.1     100.0%      +71.6%
1.5  19.0   0.0      38.2   0.1     100.0%      +100.7%
2.0  15.4   0.0      31.8   0.0     100.0%      +107.1%

lowlevel-blt-bench -n over_8888_0565:

     Before          After
     Mean   StdDev   Mean   StdDev  Confidence  Change
L1   9.8    0.0      15.3   0.1     100.0%      +56.6%
L2   7.4    0.0      14.3   0.2     100.0%      +91.7%
M    7.5    0.0      15.4   0.0     100.0%      +106.0%
HT   6.5    0.0      10.1   0.0     100.0%      +54.5%
VT   6.4    0.0      9.9    0.0     100.0%      +54.6%
R    6.2    0.0      9.5    0.0     100.0%      +52.1%
RT   4.2    0.0      4.6    0.1     100.0%      +9.8%

affine-bench * 0 0 1 over a8r8g8b8 r5g6b5:

     Before          After
     Mean   StdDev   Mean   StdDev  Confidence  Change
0.5  8.0    0.0      17.3   0.0     100.0%      +116.1%
0.75 7.8    0.0      16.5   0.0     100.0%      +112.9%
1.0  7.5    0.0      15.7   0.0     100.0%      +110.5%
1.5  7.0    0.0      14.8   0.0     100.0%      +112.8%
2.0  6.5    0.0      13.7   0.0     100.0%      +111.4%
armv6: Add fetcher for a8r8g8b8 bilinear-interpolation scaled images

This is constrained to support X increments in the positive X direction only.
It also doesn't attempt to support any form of image repeat.

Here are some affine-bench results for a variety of horizontal and vertical
scaling factors.

Before:
    x increment   0.5   0.75  1.0   1.5   2.0
y increment
    0.5            7.1   6.9   6.8   6.6   6.3
    0.75           6.4   6.2   6.1   5.8   5.5
    1.0            5.9   5.7         5.2   4.9
    1.5            5.0   4.8   4.6   4.3   4.0
    2.0            4.4   4.2   4.0   3.7   3.4

After:
    x increment   0.5   0.75  1.0   1.5   2.0
y increment
    0.5           21.0  19.6  19.2  20.2  18.9
    0.75          18.0  16.6  16.1  17.1  15.9
    1.0           21.8  18.9        19.9  17.7
    1.5           12.8  11.3  10.9  11.8  10.7
    2.0           10.7   9.3   8.9   9.8   8.8

Improvement:
    x increment   0.5     0.75    1.0     1.5     2.0
y increment
    0.5           +196.7% +183.6% +181.8% +206.6% +198.4%
    0.75          +182.2% +166.2% +164.0% +194.8% +185.8%
    1.0           +271.7% +234.4%         +282.7% +257.9%
    1.5           +154.6% +135.3% +134.3% +173.3% +164.8%
    2.0           +144.1% +124.2% +123.3% +165.6% +155.5%
armv6: Add fetcher for x8r8g8b8 bilinear-interpolation scaled images

This is constrained to support X increments in the positive X direction only.
It also doesn't attempt to support any form of image repeat.

Here are some affine-bench results for a variety of horizontal and vertical
scaling factors.

Before:
    x increment   0.5   0.75  1.0   1.5   2.0
y increment
    0.5            3.9   3.8   3.7   3.6   3.4
    0.75           3.8   3.8   3.7   3.5   3.3
    1.0            3.8   3.7         3.5   3.3
    1.5            3.7   3.6   3.5   3.3   3.1
    2.0            3.6   3.5   3.4   3.2   3.0

After:
    x increment   0.5   0.75  1.0   1.5   2.0
y increment
    0.5           20.8  19.3  18.8  19.6  18.4
    0.75          17.8  16.2  15.7  16.6  15.2
    1.0           21.3  18.4        18.9  16.9
    1.5           12.5  11.1  10.5  11.4  10.2
    2.0           10.5   9.1   8.7   9.4   8.3

Improvement:
    x increment   0.5     0.75    1.0     1.5     2.0
y increment
    0.5           +436.3% +406.2% +402.8% +448.2% +437.9%
    0.75          +364.2% +330.4% +324.7% +372.3% +354.5%
    1.0           +461.5% +392.4%         +446.9% +415.9%
    1.5           +236.3% +204.8% +198.8% +242.2% +224.1%
    2.0           +187.0% +156.5% +154.3% +193.3% +177.1%
armv6: Add fetcher for r5g6b5 bilinear-interpolation scaled images

This is constrained to support X increments in the positive X direction only.
It also doesn't attempt to support any form of image repeat.

Here are some affine-bench results for a variety of horizontal and vertical
scaling factors.

Before:
    x increment   0.5   0.75  1.0   1.5   2.0
y increment
    0.5            3.0   2.9   2.9   2.9   2.8
    0.75           2.9   2.9   2.9   2.8   2.8
    1.0            2.9   2.9         2.8   2.8
    1.5            2.9   2.9   2.8   2.8   2.7
    2.0            2.9   2.8   2.8   2.8   2.7

After:
    x increment   0.5   0.75  1.0   1.5   2.0
y increment
    0.5           20.2  18.5  19.1  17.6  16.3
    0.75          17.1  15.4  16.0  14.5  13.2
    1.0           20.1  17.1        15.6  13.6
    1.5           11.9  10.3  10.8   9.5   8.4
    2.0            9.9   8.4   8.9   7.7   6.8

Improvement:
    x increment   0.5     0.75    1.0     1.5     2.0
y increment
    0.5           +582.2% +530.7% +554.4% +514.7% +477.1%
    0.75          +481.5% +427.7% +451.2% +410.3% +371.4%
    1.0           +583.9% +486.9%         +453.3% +392.7%
    1.5           +308.1% +258.7% +281.0% +240.5% +208.1%
    2.0           +241.4% +196.9% +217.8% +179.9% +152.4%
armv6: Add fetcher for a8 bilinear-interpolation scaled images

This is constrained to support X increments in the positive X direction only.
It also doesn't attempt to support any form of image repeat.

Here are some affine-bench results for a variety of horizontal and vertical
scaling factors.

Before:
    x increment   0.5   0.75  1.0   1.5   2.0
y increment
    0.5            6.2   6.2   6.2   6.1   6.0
    0.75           6.2   6.1   6.1   6.0   5.9
    1.0            6.2   6.1         5.9   5.8
    1.5            6.1   6.0   5.9   5.8   5.6
    2.0            6.1   6.0   5.9   5.7   5.5

After:
    x increment   0.5   0.75  1.0   1.5   2.0
y increment
    0.5           22.2  21.2  19.7  21.0  20.4
    0.75          19.4  18.3  16.7  18.2  17.4
    1.0           24.7  22.3        22.1  20.4
    1.5           14.2  13.0  11.5  12.9  12.1
    2.0           12.0  10.9   9.5  10.8  10.0

Improvement:
    x increment   0.5     0.75    1.0     1.5     2.0
y increment
    0.5           +256.4% +242.8% +219.6% +246.6% +241.3%
    0.75          +212.9% +197.8% +173.7% +203.4% +195.1%
    1.0           +300.2% +265.9%         +273.4% +251.2%
    1.5           +131.8% +115.6%  +93.1% +123.2% +114.0%
    2.0            +97.7%  +82.9%  +62.8%  +91.0%  +82.9%
More accurate FAST_PATH_SAMPLES_COVER_CLIP_NEAREST|BILINEAR

A number of fast paths exist which only support "cover" type plots. These
are operations where once we transform the complete set of destination
pixels required for the plot into the source image's coordinate space, all
the required source pixels fall within the source's array bounds. This
means that there is no need for bounds checking in the inner loop, and the
selected repeat type (none, normal (aka tiled), pad, or reflect) has no
impact upon the result.

Without the needs for bounds checking, a "cover" fast path will always be
faster than an equivalent fast path which uses one of the four repeat types,
so it is unfortunate that the previous tests in analyze_extent() for
setting the two cover flags were too strict, resulting in the "cover" fast
paths being passed over in some cases where they could have been used
instead of the matching "repeat" fast path. The penalty is even higher
where there is no equivalent "repeat" fast path, as is the case with recent
ARMv6 scaled fast paths.

A worked example helps to illustrate the point. Consider a source image of
size 2,1 being plotted at the 3 pixels at the top-left of the destination
image using transformation matrix

    / 0.5 0   0.25 \
T = | 0   1   0    |
    \ 0   0   1    /

In source and destination, x and y, Pixman considers the sample at array
index i to represent the colour at the centre of the pixel with coordinates
[i, i+1). So the top three destination pixels correspond to coordinates
(0.5, 0.5), (1.5, 0.5), (2.5, 0.5). If we write these as

    / 0.5 1.5 2.5 \
D = | 0.5 0.5 0.5 |
    \ 1   1   1   /

then under the transformation, we get the equivalent source coordinates

        / 0.5 1   1.5 \
T . D = | 0.5 0.5 0.5 |
        \ 1   1   1   /

Thus output pixel 0 corresponds exactly to input pixel 0, output pixel 2
corresponds exactly to input pixel 1, and output pixel 1 depends upon the
filter type: for bilinear it's the average of the two input pixels and for
nearest it rounds half-way coordinates to -infinity, so chooses input pixel
0.

Either way, we have remained within the bounds of the source image for all
pixels, but the old code incorrectly deduced that source index -1 for both
x and y, and source index 2 for x, were required for bilinear plots and
thus wouldn't choose a "cover" fast path.

There was a similar fault for nearest-neighbour scaling, where for example
doing a two-row plot of the same source image under the transformation

    / 0.5 0   0.25 \
T = | 0   0.5 0.25 |
    \ 0   0   1    /

wrongly deduced that source index 1 for y was required when generating the
second row.

There was a section of code where the post-transformation coordinates were
enlarged by 8*pixman_fixed_e, which was largely to blame for these. The
correct way to handle rounding depends on whether we're calculating the
cover flag for nearest or bilinear scaling, and since coordinates are
handled in fixed point throughout, there is a precise correct amount to
adjust each by, rather than an arbitrary fudge factor.

Running fuzzer-find-diff.pl on scaling-test for a number of hours has not
been able to identify any cases where the results of this new version are
incorrect.
pixman-fast-path: Add fast path for "pad" type repeats

Similar in concept to fast_composite_tiled_repeat(), this breaks up any
unscaled composites, where source/mask areas outside the bitmap grid are
not clipped, into a series of simpler composites (either bitmap to bitmap
or solid to bitmap). These simpler composites are usually likely to match
existing fast path implementations, and so should benefit all platforms.

This produces some significant speedups for some cairo-perf-trace tests.
For example, timings on ARMv6 (using Siarhei's trimmed traces) are

Before:
[ # ]  backend                         test   min(s) median(s) stddev. count
[ # ]    image: pixman 0.29.3
[  0]    image         t-firefox-chalkboard   35.715   35.736   0.03%    6/6

After:
[ # ]  backend                         test   min(s) median(s) stddev. count
[ # ]    image: pixman 0.29.3
[  0]    image         t-firefox-chalkboard    9.254    9.261   0.15%    6/6

That's a speedup of 3.86x.

Also added a simple test program to check different repeat types.