Deorbit the netscape plugin

Netscape hasn't been a thing since 2008.

We would only try to build it if someone manually ran 'webinstall'
in src/libuafs, and there is no documentation telling anyone to do so.

It's dead, Jim.

Change-Id: I7486ca33da7ff19f23f0d9f54f5fb4e7e3232540
Deorbit separate JUAFS build

Since 80943970b8cfcdf3fc630b25804aebaea228bd73, when the web enhancements
were enabled universally, there has no longer been a functional difference
between the UAFS and JUAFS builds.  Their object files are compiled
using the same compilation rule, and the list of object files differed
only by rx_kmutex.o (which is devoid of content) and xdr_int32.o
(which is preumably an oversight).

Save the extra build time by just reinstalling libuafs.a as libjuafs.a
to preserve the existing interfaces.

Additionally, drop the LIBJUAFS make variable -- all definitions set
it to libjuafs.a.  Similarly, the LIBJUAFS_FLAGS variable was unused
and can be removed.

Change-Id: I2074d5bc26e326db36b16e055431818ef1c69210
Build libuafs with lwptool

Use the standard program for building slightly different object files
into their own directories, instead of rolling our own.  This allows
us to pull the build rules into the Makefile.common, leaving just
compiler flags and similar in the MakefileProtos.

We do have to hack around the standard libtool build rules a little
bit in order to get things compiled using the same compiler and arguments
that the old build system used, but it does not seem too bad.

As a side effect, we get rid of the LIBUAFS make variable -- all sites
were defining it to libuafs.a anyway, so we can just hardcode it.

While here, adjust the linktest build rule to directly consume
libafshcrypto.a instead of using LIB_hcrypto.  This is the only consumer
of libafshcrypto which is not using libtool to link, which prevents us
from setting LIB_hcrypto to point to the .la file.

Change-Id: I2bda2f40bbd0aa808c24e074d2d7bcd329f6b77e
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
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
Use libtool versions of hcrypto

Change-Id: I6da3af2547897555d2433df836676f6b6c44a060