configure: check for mprotect

Signed-off-by: Mans Rullgard <mans@mansr.com>
swscale: try to use mmap only if available

Some systems, e.g. Minix, have sys/mman.h defining MAP_ANONYMOUS without
providing (working) mmap and friends.  The mmx filter generation code
checks only for MAP_ANONYMOUS, not for availability of mmap itself which
leads to build errors on aforementioned systems.

This changes the conditional compilation to use mmap only if all the
required functions are available.

Signed-off-by: Mans Rullgard <mans@mansr.com>
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: Split out msvc as a separate target OS

The name mingw32 as target OS is both misleading, and very little
of the target OS specific settings actually match.

Since the target OS default is set based on uname, the default
(which on MSYS is set to mingw) is overridden by --toolchain=msvc.
Add support for building shared libraries with MSVC

This requires the makedef perl script by Derek, from the c89-to-c99
repo. That scripts produces a .def file, listing the symbols to be
exported, based on the gcc version scripts and the built object files.

To properly load non-function symbols from DLL files, the data
symbol 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.)

The __declspec(dllimport) attribute is added via a macro. Since
it has to be present when building code that refers to these symbols,
but not be present while building the library that exports the symbols
themselves, the Makefile is modified to add a define like
COMPILING_<libname> while building each library. This is used in the
definition of the <lib>_exportdata macro - on non-MSVC compilers, it is
empty. On MSVC, it is __declspec(dllimport) for declarations in other
libraries than the object file currently compiled.

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. (That is, static libraries as such can be,
and actually are, built - this is used for linking the test tools to
internal symbols in the libraries - but e.g. libavformat object files
built to link to libavcodec as a DLL cannot link statically to
libavcodec.)

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
to 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 instead of
the static library.