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.

This also implies that code that is built to link to a certain
library as a DLL can't link to the same library as a static library.
Therefore, we only allow building either static or shared but not
both at the same time. (Internally, however, a static library is
created for collecting the built objects, for linking the test tools
to non-exported functions in the library.)

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,
you need to literally specify the name of the import library (or static
library).
build: Don't pass DEP_LIBS as parameters to the linker

DEP_LIBS is part of $^, since DEP_LIBS is a dependency of the
test tools. The libs, that originate in the FFLIBS variable,
are added into FFEXTRALIBS already (normally in the form -lavutil),
but via DEP_LIBS in the literal form as libavutil/libavutil.so.

Previously, when building test tools, the make file invoked
the linker with the parameters "libavutil/libavutil.so -lavutil".
On linux this worked just fine.

On mingw, the linker actually can handle being given both the literal
DLL name or using the -lavutil parameter (and handle multiple copies
of them), but when using both forms at the same time for the same
library, the mingw linker trips up.

On msvc, the linker can't handle being passed the literal DLL name
at all.

This fixes running fate on mingw with DLLs enabled.
build: Use LD_LIB for THIS_LIB when building tools/examples

This fixes building tools/examples with DLLs with MSVC.

The MSVC linker can't handle being given a direct DLL name as
parameter, but must use the import libraries (which are handled
via LD_LIB).