dcadsp: move int8x8_fmul_int32 to dsp context

It is currently declared as an inlinable function, with C and Neon
implementations found in headers.

On an Arrandale CPU, gain for an SSE2 function of that inlining vs. a call:
- Win32: 29 to 26 cycles
- Win64: 25 to 23 cycles
x86: dcadsp: implement int8x8_fmul_int32

         C  SSE  SSE2  SSE4
Win32:  47   42   29    26
Win64:  30   33   25    23
Consequently, the SSE version is neither compiled nor set for 64bits.
save inline version.
dcadsp: split lfe_dir cases

The x86 runs short on registers because numerous elements are not static.
In addition, splitting them allows more optimized code, at least for x86.
x86: dcadsp: implement SSE lfe_dir

Results for Arrandale/Windows:
32: 1670 -> 316
64:  728 -> 298
dca dsp C: factorize scaling in lfe_fir

Scaling on output leads to respectively 32 or 64 multiplications, while doing
it on the input is respectively 8 or 4 multiplications. As a side note,
the trick can be used in other implementations.

Win64: 728 to 562 cycles.
dcadsp: scan linearly coeffs instead.

Win32: 1680 cycles to 1580.
x86: synth filter float: implement SSE2 version

Timings for Arrandale:
          C    SSE
win32:  2108   334
win64:  1152   322

Factorizing the inner loop with a call/jmp is a >15 cycles cost, even with
the jmp destination being aligned.

Unrolling for ARCH_X86_64 is a 20 cycles gain.
dcadsp: split synth_filter_float

The goal is to avoid function calls within assembly which are a mess on x86.
dca: replace some memcpy by AV_COPY128
fmtconvert: int32_t input to int32_to_float_fmul_scalar

It was previously declared as int.
Does not change fate results for x86.
dca: factorize scaling in inverse ADPCM

The codeblock affected accounted for around 4% of the runtime on x86_64
(measured using oprofile on a Penryn).
Timings for Arrandale (gcc 4.6.1 tdm64-1 for windows):
win32: 341 -> 331
win64: 321 -> 120
Part of the gain also comes from the adpcm values to be converted to float
outside of the loops.
x86: float dsp: unroll SSE versions

vector_fmul and vector_fmac_scalar are guaranteed that they can process in
batch of 16 elements, but their SSE versions only does 8 at a time.

Therefore, unroll them a bit.
299 to 261c for 256 elements in vector_fmac_scalar on Arrandale/Win64.
dcadec: use av_intfloat32 to negate values

On Arrandale/Win64, 97 to 80 cycles. The codeblock accounts for 3% of the
decoding time, conversion from float to int16 included.