ffmpeg: Add armv6 acceleration for imdct/fft used by ac3/aac

armv6: Accelerate ff_imdct_half for general case (mdct_bits != 6)

The previous implementation targeted DTS Coherent Acoustics, which only
requires mdct_bits == 6. This relatively small size lent itself to
unrolling the loops a small number of times, and encoding offsets
calculated at assembly time within the load/store instructions of each
iteration.

In the more general case (codecs such as AAC and AC3) much larger arrays
are used - mdct_bits == [8, 9, 11]. The old method does not scale for
these cases, so more integer registers are used with non-unrolled versions
of the loops (and with some stack spillage). The postrotation filter loop
is still unrolled by a factor of 2 to permit the double-buffering of some
VFP registers to facilitate overlap of neighbouring iterations.

I benchmarked the result by measuring the number of gperftools samples
that hit anywhere in the AAC decoder (starting from aac_decode_frame())
or specifically in ff_imdct_half_c / ff_imdct_half_vfp, for the same
example AAC stream:

                  Before          After
                  Mean   StdDev   Mean   StdDev  Confidence  Change
aac_decode_frame  2368.1 35.8     2117.2 35.3    100.0%      +11.8%
ff_imdct_half_*   457.5  22.4     251.2  16.2    100.0%      +82.1%

armv6: Accelerate ff_fft_calc for general case (nbits != 4)

The previous implementation targeted DTS Coherent Acoustics, which only
requires nbits == 4 (fft16()). This case was (and still is) linked directly
rather than being indirected through ff_fft_calc_vfp(), but now the full
range from radix-4 up to radix-65536 is available. This benefits other codecs
such as AAC and AC3.

The implementaion is based upon the C version, with each routine larger than
radix-16 calling a hierarchy of smaller FFT functions, then performing a
post-processing pass. This pass benefits a lot from loop unrolling to
counter the long pipelines in the VFP. A relaxed calling standard also
reduces the overhead of the call hierarchy, and avoiding the excessive
inlining performed by GCC probably helps with I-cache utilisation too.

I benchmarked the result by measuring the number of gperftools samples that
hit anywhere in the AAC decoder (starting from aac_decode_frame()) or
specifically in the FFT routines (fft4() to fft512() and pass()) for the
same sample AAC stream:

              Before          After
              Mean   StdDev   Mean   StdDev  Confidence  Change
Audio decode  2245.5 53.1     1599.6 43.8    100.0%      +40.4%
FFT routines  940.6  22.0     348.1  20.8    100.0%      +170.2%
[rbp] Add config.txt settings to log file
[omxcodec] Updates to work better with dropping and lateness detection
[omxplayer] Add ability to log more timestamp info in extra debug settings
[omxplayer] Add ability to dump out audio/video data for later debugging
[omxcodec] Reduce GPU memory use by 2 video frames
[pi] Fix for logged resolutions
[settings] Experiment: Report DESKTOP resolution in video settings
[omx] Remove logging for texture jobs

This causes a lot of log spam which hasn't proved useful so far.
changed: avoid useless filesytem io while searching for subtitles
[pisink] Support planar formats
[rbp] Hardware accelerated resampling

This replaces the format conversion, up/down mixing and resampling code from ActiveAE with a GPU accelerated version.
Should significantly reduce CPU when using paplayer or dvdplayer.

Requires updated firmware
[resamplepi] Support planar formats
gles: Avoid crash when capturing snapshot when using dvdplayer

Note: snapshot will be blank, but that's better than crashing
sqlite: Bump to 3080500
[experimental] Disable quiet-noise generation
[omxcodec] Adjust asserts
Added some vc_tv_* functions that were missing in DllBCM.
Added private utility function to map a float display aspect, to the respective SDTV_ASPECT_* enum value.
Changed SDTV resolutions to be treated similarly to HDMI resolutions in SetNativeResolution. This means that the SDTV interface is powered up and set to the right mode.