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 so it doesn't do the generic code, but the MSVC build
doesn't try to do this.) On real windows, it seems to finish pretty
quickly.
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.
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: Fix building testprogs/examples/tools with DLLs