Integration of k5start/krenew functionality

[Sam Hartman]

I find it very difficult to comment on this because I don't understand
the use case.  I'm not complaining--I like how this was handled very
much, but internal discussions between MIT and an OS vendor are not
(and should not generally be) my business.

So, I'll give some priorities to consider.

1) If the problem is political, look for political solutions.  I.E. if
the existing k5start would be good enough, but the OS vendor is
concerned that Russ is not a large enough organization to rely on,
look into working with Russ to provide better support/fallback options
in case Russ gets kidnapped by aliens.

2) Slightly different interfaces that are hard to tell apart are
really annoying.  If it is not going to be the same code, don't call it k5start.

3) Duplication of interface is also incredibly annoying. I think as an
administrator I'd rather something that was plug compatible either to
k5start or to kcm (although with a different name if it was not going
to follow identical evolution) than something entirely new.

4) If you do decide to have a new interface try to clearly describe why your use case is different than the existing interface, so I can figure out when I should be using your thing rather than k5start.  

5) Plugins are good.  AFS, Linux keyring management (establisg a session keyring), etc all could use plugins.  Depending on things like pagsh is administrator-hostile.

--Sam