Normalize names of libtool convenience libraries

Part of why libtool was introduced into the tree was to reduce the
number of times each source file is compiled.  PIC code is needed
for shared objects, and non-PIC code for static libraries, so in most
cases a C file must be compiled twice, but not more than that.

Libtool automatically manages which version of an object is passed to
the linker when libtool is used to link .la files.  At several places
in the tree (libafsrpc, libafsauthent, libuafs_pic.so, and pam_afs.so)
we use libtool to link a .la library and pass other .la libraries in
as linker inputs.  In normal situations, libtool would produce an
output shared library that registered a shared library dependency on
the (shared version of the) input library.  However, in our usage,
these input .la libraries are used only for our convenience, and are
not intended to be installed, so libtool would produce an output
library that was not usable.

Libtool refers to our usage of libraries not intended to be installed
as "convenience libraries"; for us, they are essentially just
static archives that contain PIC objects (as opposed to normal
static archives which contain non-PIC objects).

Prior to this commit, we had named our convenience libraries things
like libafsauthent_auth.la or libafsrpc_comerr.la, since they were
mostly only used for either libafsrpc or libafsauthent.  However,
future commits will need to use some of these convenience libraries
in other shared objects (such as pam_afs.so), so we normalize the
library name to indicate merely that it is a PIC version of that
module.

There are three exceptions to this rule: libafsrpc_sys.la, which
contains only a single file and not the whole of the sys module,
libafsrpc_util.la, which contains a subset of the util objects,
and libauthent_ubik.la, which contains a subset of the ubik
objects.  Since these convenience libraries are in fact tailored to
the particular application, a target-specific name is appropriate.

The convenience library provided by the ptserver module is named
libprot_pic to match the existing public interface libprot.a.

We cannot link the dependencies of the convenience libraries
directly into them, because any given object may only be linked
once into a given library, and our dependency graph between
modules is decidedly not a tree, so attempting to link in the
dependencies would result in duplicate symbol errors.

Change-Id: I5f10af74b8582edd51e5f1b3f0026dbc7ef9f7ad
Reviewed-on: http://gerrit.openafs.org/11459
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: D Brashear <shadow@your-file-system.com>
Tested-by: D Brashear <shadow@your-file-system.com>
Normalize LT_deps/LT_objs split

As described in the commit message of
69f26ece3c4545ecc9099641f7a507796fe9dc77, LT_objs should contain
the .lo files for the given module, and LT_deps should contain the
libtool dependencies, i.e., the .la files from other parts of the
tree.  However, this simple split by file suffix is not correct
when we are using convenience libraries.  Really, LT_objs represents
the "new" objects being provided by the module, and LT_deps is
libraries from other modules that provide functionality on which
we depend.  Since convenience libraries are just thin aggregates
of object files, they behave more like object files than libraries
upon which we depend.  In particular, libafsrpc and libafsauthent
are wrapper libraries that gather together the functionality of
several modules and export them as a single library interface;
they do not have any objects of their own.

However, libafsauthent has a dependency on libafsrpc, which does
belong in LT_deps (or possibly in LT_libs).

Simon's description of LT_libs leaves a little ambiguity, as it
does not describe what should be done with non-libtool libraries
from within OpenAFS.  (At present, these include libafshcrypto
and librokenafs, both of which are regularly put in LT_libs.)
I prefer to recast LT_libs as containing externally visible libraries,
not just external libraries, which rationalizes the inclusion of
roken and hcrypto there, since we currently install those libraries,
and build libraries that have shared library dependencies on them.

In the future, as we begin committing to stable shared library
interfaces for libraries produced by libtool, I would like to
have those .la files be moved to LT_libs, since they would then
be external library dependencies of the given module.

Change-Id: Ie50010da84df99cec048c3e39ffeb9d5897fc08c
Reviewed-on: http://gerrit.openafs.org/11460
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: D Brashear <shadow@your-file-system.com>
Tested-by: D Brashear <shadow@your-file-system.com>