libsemanage: install to LIBDIR instead of SHLIBDIR

The libsemanage Makefile currently installs libsemanage.so.1 into
SHLIBDIR, but links libsemanage.so to libsemanage.so.1 in LIBDIR. This
means things will only work if SHLIBDIR and LIBDIR are the same.
Fortunately, by default, they are the same because the default of
SHLIBDIR is set to PREFIX/lib (same as LIBDIR default) instead of the
standard DESTDIR/lib.  Unfortunately, if a user overrides SHLIBDIR, by
doing something like the following:

    make DESTDIR=~/tmp/ LIBDIR=~/tmp/usr/lib SHLIBDIR=~/tmp/lib install

then a broken symlink is created. Note that in some cases this may still
work even when SHLIBDIR and LIBDIR are not the same, e.g.:

    make LIBDIR=/usr/lib64 SHLIBDIR=/lib64 install

But this only works because, in systems like Fedora, /lib is a symlink
to /usr/lib, so SHLIBDIR and LIBDIR are the same even though it doesn't
immediately look like it.

This patch changes the libsemanage Makefile to set the default value of
SHLIBDIR to the standard DESTDIR/lib to prevent confusion, and installs
libsemanage to LIBDIR and completely ignores SHLIBDIR.

Signed-off-by: Steve Lawrence <slawrence@tresys.com>
libselinux: libsepol: use ln --relative to create .so symlinks

The current build system assumes SHLIBDIR is ../../ relative to LIBDIR.
However, this isn't always the case. For example, Arch Linux sets both
LIBDIR and SHLIBDIR to /usr/lib, which results in broken symlinks.

Instead of making that assumption, create .so symlinks using ln
--relative so that the correct relative paths are used. Note that this
adds a dependency for the build system to use coretuils-8.16 or later.

Fixes #2

Reported-by: Nicolas Iooss <nicolas.iooss@m4x.org>
Signed-off-by: Steve Lawrence <slawrence@tresys.com>
Bump to release candidate 5