timefilter: De-doxygenize normal code comments and drop silly ones
adpcmenc: ensure calls to adpcm_ima_compress_sample() are in the right order

Should fix fate-acodec-adpcm-ima_wav with several compilers.
avcodec: allow either planar or interleaved sample format when encoding mono

When there is only 1 channel, the planar and interleaved formats of the same
data type should be treated as identical.
af_resample: avoid conversion of identical sample formats for 1 channel

When there is only 1 channel, the planar and interleaved formats of the same
data type should be treated as identical.
random_seed: Rewrite generic code

The new code is faster and reuses the previous state in case of
multiple calls.

The previous code could easily end up in near-infinite loops,
if the difference between two clock() calls never was larger than
1.

This makes fate-parseutils built with MSVC finish in finite time
when run in wine. (The one built with mingw actually manages to find
/dev/urandom, but the MSVC build doesn't try to do this.)
Revert "configure: x86: improve ebp availability check"

This makes cabac-test work on 32-bit mingw, to ease testing/comparison
between MSVC and mingw.

This reverts commit 692dd8ed2617f390ff53b1152a21170e886be726.
configure: Name the static libraries foo.lib instead of libfoo.a on MSVC

The convention on MSVC is to name libraries this way. This both
changes what the static libraries are named within the build
(which is only a internal detail, where it hasn't mattered
that they were named the unix way before), but also changes what
they are named when they are installed, making it match the MSVC
convention.

This also interacts with shared library building, which is to come.
The DLL import libraries are named the same as the static libraries,
which might be required to make some thing work somewhere.

Without this, building the shared library fails, when one library
is supposed to be linked to another, linking it tries to use
'libfoo.a' to link to it, while the import library is named
'foo.lib'. (Obviously, the alternative would be to make the DLL
build process output import libraries named libfoo.a as well.)
Shared library support for MSVC build.

This patch adds support for .dll shared library generation using MSVC's
native build tools.

This requires the makedef perl script by Derek, which probably will
go into the c99-to-c89 repo.

To properly load non-function symbols from DLL files, the declarations
need to have the attribute __declspec(dllimport) when building the
calling code. (On mingw, the linker can fix this up automatically,
which is why it has not been an issue so far. For code built with
MSVC linking to DLLs built by mingw, one has had to manually add
this into the headers, if using the data symbols.)

The __declspec(dllimport) attribute is added via a macro. Since
it has to be present when building code that refer to these symbols,
but not be present while building the actual library, the makefile
is modified to add a define like COMPILING_avcodec while building
each library. This is used in the definition of the AV<lib>_SYMBOL
macro - on non-MSVC compilers, it is empty. On MSVC, it is
__declspec(dllimport) as long as the code currently built is for
another library than the current one.

Only libavutil have got data symbols in the public installed headers,
so the new symbols.h header is an installed header only in that library,
in libavcodec it is only used for avpriv-prefixed symbols.

Having this part of the installed headers requires adding the new
define AV_HAVE_SHARED_LIBS to avconfig.h - one single build on MSVC
can only be either shared or static but not both anyway.

An alternative to this would be to require callers to define
something like AV_LIB_DLL, when building calling code which is
supposed to link to the DLL instead of static libraries.

Also, linking to DLLs is slightly different from linking to shared
libraries on other platforms. DLLs use a thing called import
libraries, which is basically a stub library allowing the linker
know which symbols exist in the DLL and what name the DLL will
have at runtime.

In mingw/gcc, the import library is usually named libfoo.dll.a,
which goes next to a static library named libfoo.a. This allows gcc
to pick the dynamic one, if available, from the normal -lfoo switches,
just as it does for libfoo.a vs libfoo.so on unix. On MSVC however,
both the static libraries and the import libraries are named the same,
foo.lib - normally one only builds one of them.

This also causes some confusion for dependencies in make. The import
libraries (which have the same name as the static libraries) are
produced as an undeclared side product when building the DLLs
(by SLIB_EXTRA_CMD). The internal test applications have direct
dependencies on the static libraries, so if the import libraries
haven't been produced already when they are required (during parallel
builds), make will actually create it as a normal static library
(since make has rules for doing that). Currently this is worked
around by first doing a full build ("make -jX") before making fate -
this ensures that all DLLs are built already before building the
test tools, so the static library build rules aren't invoked.

Currently doing make fate doesn't work though, since we only have
shared libraries available, and those don't export the internal
symbols needed for the tests.
Hack test tool deps to make sure building of them work with MSVC DLLs

The way of making the test tools link against static libraries
doesn't currently work with mingw DLL builds either.

When building e.g. dct-test.exe, the linking command line contains
the following:

libavcodec/avcodec.dll libavutil/avutil.dll libavcodec/libavcodec.a -lavcodec -lavutil

This ends up with the following linker errors:
d000000.o:(.idata$2+0x0): multiple definition of `__head_avutil_51_dll'
libavutil/libavutil.dll.a(d000000.o):(.idata$2+0x0): first defined here
d000001.o:(.idata$5+0x0): multiple definition of `__imp__av_pix_fmt_descriptors'
libavutil/libavutil.dll.a(d000152.o):(.idata$5+0x0): first defined here
d000001.o:(.idata$6+0x0): multiple definition of `__nm__av_pix_fmt_descriptors'
libavutil/libavutil.dll.a(d000152.o):(.idata$6+0x0): first defined here
d000002.o:(.idata$5+0x0): multiple definition of `__imp__av_reverse'
libavutil/libavutil.dll.a(d000162.o):(.idata$5+0x0): first defined here
d000002.o:(.idata$6+0x0): multiple definition of `__nm__av_reverse'
libavutil/libavutil.dll.a(d000162.o):(.idata$6+0x0): first defined here
d000003.o:(.idata$7+0x0): multiple definition of `_avutil_51_dll_iname'
libavutil/libavutil.dll.a(d000221.o):(.idata$7+0x0): first defined here

After this patch, the DLL files in the linker command line are removed,
so the section of the linker command line above becomes:
libavcodec/libavcodec.a -lavcodec -lavutil
This succeeds to link.

Similarly, for MSVC, originally when building the test tools, the
linker parameters were:
libavcodec/avcodec.dll libavutil/avutil.dll libavcodec/avcodec.lib avcodec.lib avutil.lib
This ends up with the following errors:
libavcodec/avcodec.dll : fatal error LNK1107: invalid or corrupt file: cannot read at 0x2B8
After this patch, the linker parameters are:
libavcodec/avcodec.lib avcodec.lib avutil.lib

This succeeds linking, but has the caveat that avcodec.lib is a DLL
import library, so it can only link to the functions that are exported
from the DLL.
Export an extra symbol for filtfmts-test
Export symbols used by golomb-test
Export symbols used by fft-test
Export symbols used by dct-test
Export more symbols for colorspace-test