Use different LDFLAGS for static versus dynamic libraries.

If LDFLAGS is specified in site-slib.def, and we are building a
dynamic library, copy those flags over to site.def.  (Note that,
confusingly, site-slib.def is used only for building the dynamic
libwfdb, whereas site.def is used for building both the static libwfdb
and the applications.)

This is a little kludgy, but will allow us to use the correct LDFLAGS
in all cases, since often the LDFLAGS needed for a static library are
not the same as those needed for a dynamic library.
Various fixes to LDFLAGS.

On Cygwin, Darwin, FreeBSD, Linux, MinGW, do not include $(LL) in
LDFLAGS when linking to a shared libwfdb.  On those platforms, libwfdb
is linked with libcurl if necessary; it is not necessary or
particularly helpful for applications to be linked with libcurl as
well.  (The same may also be true of Solaris and HP-UX, but I'm not
sure.)

On Darwin, FreeBSD, and generic, when building libwfdb itself, place
$(LL) in the correct position in the command line (after the list of
object files.)  I don't know if this is actually necessary or not, but
it won't hurt.  It's necessary if the linker works from left to right
and uses "--as-needed"-like behavior by default.

On FreeBSD (static libwfdb) and Solaris (shared libwfdb), use the
correct variable ($(LL) rather than $(LDLIBWWW) $(LDLIBCURL).)
Define RPATHFLAGS for various systems.

This variable needs to be defined in both foo.def and foo-slib.def,
but it'll only actually be used if we are building a shared library,
so it should only be mentioned in LDFLAGS in foo-slib.def.

These should work on Linux and FreeBSD at least.  Solaris is a shot in
the dark, as is HP-UX.  Darwin seems not to support RPATH but maybe
doesn't need it?  MinGW and Cygwin of course have nothing like RPATH.

Also, on Linux, do not use --no-as-needed.
On FreeBSD, use $(CC) to build the shared library.

Appears to work fine with cc (clang) on FreeBSD 10.
Use /usr/local/lib as default LIBDIR.

In general, use $(WFDBROOT)/lib as LIBDIR unless the user manually
specifies --libdir to configure.  If the user specifies '-m32', use
$(WFDBROOT)/lib32 instead.

However, if '$(WFDBROOT)/lib64' is a standard library search directory
for the native architecture (as determined by the C compiler), then
use $(WFDBROOT)/lib64 for the native architecture, and $(WFDBROOT)/lib
for -m32.  (The effect of this is that, on Fedora, if you specify
--prefix=/usr, you will get the historical behavior.)

There are a few points to be made here:

 - /usr/local/lib is widely accepted, by basically everyone except Red
   Hat, as a standard location for installing libraries for the native
   architecture (regardless of what that architecture might be.)  It
   is also in the default ld.so search path on many systems, so on
   those systems 10.5.24 can be backwards compatible with 10.5.22, and
   programs can potentially avoid using RPATH.

 - /usr/local/lib64 is not a standard location according to anybody
   (not even Red Hat.)

 - Nowadays the only reason most people need a 32-bit libwfdb at all
   is for WAVE.  Since WAVE is built as part of the WFDB package we
   can ensure it gets built with the proper RPATH if necessary.

 - Backwards compatibility with 10.5.23 (in terms of RPATHs) is mostly
   a non-issue, since wfdb-config was unusable in 10.5.23.