Adjust roken.m4 to allow separate lib and include

In some installations (e.g., Debian), the roken libraries and headers
will not be installed in a common root directory to which /lib and
/include may be appended to find the appropriate library and header
directories, respectively.

Take inspiration from rra-c-util's GSSAPI macros and allow the
specification of separate include and lib directories.  Since there
are now three values to pass to the guts of the checking routine,
pass them in global variables instead of as parameters.

The expected usage would be to set either --with-roken, or both of
--with-roken-libdir and --with-roken-includedir, as in
configure --with-roken-include=/usr/include/heimdal
--with-roken-lib=/usr/lib/x86_64-linux-gnu/heimdal

Change-Id: I6f651ef3f3abf37c92ea81ea1801294ca3dc00b2
Allow building with MIT krb5 and external roken

That is, an external roken which is part of a heimdal distribution,
with full headers and libraries, most notably krb5.h and libkrb5.

This adjusts the ordering of file- and module-specific compiler and
linker arguments so that the more specific arguments are able to
take precedence.  For general flags arguments, such as enabling
or disabling warnings or features, the more-specific settings should
come last, so as to override the flags set by default.  However,
for arguments that affect a global search list (e.g., for headers
or libraries),  the more-specific arguments must come first, so
as to be at the beginning of the search list.

We presently use per-file CFLAGS for both warning-type flags and
preprocessor (i.e., include path) type flags, so add an additional
file-specific setting for CPPFLAGS, which comes at the beginning of
the compiler invocation.

At present, MODULE_CFLAGS are essentially only used for preprocessor
functionality, so treat them as CPPFLAGS and put them right after
the per-file CPPFLAGS.  (It might be cleaner to rename them to
MODULE_CPPFLAGS, but that would be more churn than is needed.  If
such a distinction turns out to be necessary, it can be done at a
later date.)  Likewise the MODLE_LDFLAGS are generally being used
to affect the library search path, so put them early as well.

Make the necessary Makefile changes to use these new features to
allow building with MIT krb5 and external roken: put KRB5_CPPFLAGS
in per-file CPPFLAGS, and put LDFLAGS_KRB5 in MODULE_LDFLAGS for
aklog.

Change-Id: I1091223b3b75c782b39b9e189bdd47e52ebefae2
Fix LT_LDLIB_shlib_missing

Libtool's -symbols-file argument is taken as an exact match of symbols
that this library claims to export.  It does not filter based on what
symbols are actually present in the objects comprising the library.
Instead, if there are symbols in the file which are not implemented
by the library, there is an implicit assumption that some other library
will provide those symbols, which must be linked into a consumer of
this library alongside this library.

These are not the semantics we want (at present, only for roken), wherein
a library will implement some (but probably not all) of a given list
of symbols, and we want the export list to reflect only those symbols
which are implemented.  Insead, use the symbols file to build a regex that
will only match symbols listed in the file (and no other symbols), and
only export the subset which is present.

Change-Id: Id81f7a35089ae7f760fe643680f9bfb9c81521aa
Build roken using libtool

Previously it was version 1.1; just in case I did something terrible,
bump it to 2.0, as was done for the other libtool conversions.

Change-Id: If6ab6c2d57c0a1b1511f9631b9aeb522d7e7392b
Build hcrypto with libtool

XXX changes LIB_roken and LIB_hcrypto in hacky ways.

Or rather, with lwptool, since we need a LWP version as well as
the various pthreaded versions.

The previous version was the initial version, 1.1, but since we're
switching to libtool, bump the version to 2.0 just to be safe.

Libtool abstracts away the extra logic that had previously been needed
to build different copies of rand-fortuna for the pthreaded and LWP
libraries.

Change-Id: Ibc530a1fa4baa7a38b44eb3e0719e1905a6fe269
Build venus tests with libtool

This was the only place doing -lafshcrypto_lwp on the command line.
(There are other consumers, which list libafshcrypto_lwp.a explicitly.)

Change-Id: Ibc99615d2ff03b8aebf956502a2a6b1cb26f0a65
Use libtool versions of hcrypto

Change-Id: I6da3af2547897555d2433df836676f6b6c44a060