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.
Exactly where this is required, if anywhere, is to be determined.
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
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