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.

Install both the libtool archive and the static archive to $(TOP_LIBDIR),
so that all our internal consumers can just use -L$(TOP_LIBDIR) -lrokenafs
(well, via the LDFLAGS_roken and LIB_roken aliases) whether linking
statically or shared.  Installing the libtool archive gets us the shared
library there, but we have to then remove the libtool archive, since
this is not the location we told libtool we would install to (the prefix
we configured with), and libtool would get confused trying to use this
installed, but installed-at-the-wrong-place libtool archive.

It is tempting to eschew this installation and instead point LIB_roken
at the libtool archive file librokenafs.la directly (with empty
LDFLAGS_roken), but this is not possible until all consumers of roken
are converted to build using libtool.  In practice, this will probably
not happen until LWP is evicted from the tree.

Change-Id: If6ab6c2d57c0a1b1511f9631b9aeb522d7e7392b
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;
we can use the presence of libafshcrypto_lwp.a to track progress towards
not needing a LWP hcrypto build, which must come from the in-tree version.)

Convert the tests to build with libtool (as pthreaded), where we can
just throw in $(LIB_hcrypto) and deal with what we get.

Change-Id: Ibc99615d2ff03b8aebf956502a2a6b1cb26f0a65
Link aklog against LIB_hcrypto

This was the last place where libafshcrypto.a was explicitly referenced,
preventing the use of an out-of-tree hcrypto library.

We will continue to need to build the in-tree code to produce a
libafshcrypto_lwp.a library for use in LWP applications, until we
do not have any more LWP applications, but some systems (such as
Debian) have a desire to avoid bundled libraries, so we should
facilitate the use of an external libhcrypto where possible.

Many consumers of libafshcrypto_lwp.a will be removed when the
LWP versions of various modules are removed after 1.8 is branched.

Change-Id: I23049866caae9c16ffb2ec32c5e7b058465a26ba
Allow external hcrypto

Put the configure checks into a separate file in src/cf, following
the same general structure as the roken checks.

Allow explicitly requesting the internal version, or checking
what's in the default paths, or providing a specific hcrypto root
or lib/include dirs for Debian compatibility.

We must still always compile libafshcrypto_lwp.a for use by LWP
binaries, from the bundled sources, but other binaries will use
the system version.

The hcrypto headers have an unfortunately large number of dependencies,
including depending on being able to find each other by including
<hcrypto/foo.h> paths.  As such we must pass both the user-supplied
directory and $dir/hcrypto to the preprocessor in order for things
to work, and we also may need to revisit the includes used in the
configure check for use on non-linux systems due to the dependencies
on system headers.

Change-Id: Idcba1418a19a7b562335524c911d69dc84268177
Build hcrypto with libtool

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.

As for roken, we must install both shared and static libraries
to $(TOP_LIBDIR) for unity of consumption, but remove the libtool
archive after instllation.

Change-Id: Ibc530a1fa4baa7a38b44eb3e0719e1905a6fe269