Proposed libverto integration plan

[ghudson@MIT.EDU]

Here's an outline of what I plan to do to handle the libverto
dependency in 1.10, taking into account the discussion thread:

1. Bundle the libev source in util/k5ev.  If util/k5ev is built, it
will install just a shared library named libk5ev and no header.

2. Bundle the core libverto source in util/verto, along with a k5ev
module for it (just a copy of libverto-ev.c adjusted for the libk5ev
symbol names).  If util/verto is built, it will install the libverto
shared library, verto.h, and the libverto-k5ev module, but no other
verto modules and no verto-k5ev header.

3. Add a libverto-k5ev module to the bundled libverto which is just a
copy of the libev module adjusted for the libk5ev symbol names.

4. If you configure with --with-system-verto, the bundled verto and
k5ev sources will never be built and the build will require that it
finds an installed verto library and header.

5. If you configure with --without-system-verto, the bundled verto and
k5ev sources will always be built and installed.

6. If you don't specify either, the build will look for an installed
verto and use it if it finds one; if not, it will build the bundled
verto and k5ev.

What I like about this plan:

* krb5 continues to build and work on older systems with no special
  libraries installed.

* For the verto integration, we won't have to add autoconf grot to
  detect glib/libevent/etc. because we won't be installing those
  modules.  The core verto code will require only minimal autoconf and
  Makefile.in grot.

* libev is significantly smaller than libevent.  Plus, we can do the
  build system integration and renaming very easily using libev's
  support for embedding.

* The bundled libk5ev won't conflict with an installed (possibly too
  old to use) version of libev.

What I'm nervous about:

* In theory, a system could have libverto but no suitable backing
  module.  We either need to ignore this case as too rare to worry
  about (if it does happen, we build a KDC which will fail gracefully
  at startup) or detect it at configure time by compiling and running
  a program against the system libverto.

* If the bundled libverto is used, it conflicts with a subsequently
  installed real libverto but doesn't provide the full set of libverto
  modules for applications.

* This is enough work that it presents some minor scheduling issues
  since I'm in the middle of the credential selection work.  This may
  mean we delay the integration of Nathaniel's patch for a couple of
  weeks; hopefully this wouldn't be a big deal since he's using git.