Disconnect the texinfo users guide from the build

Its content has been migrated to or superseded by the krb_users
reST documentation.

The texinfo document attempted to have a general introduction to
Kerberos, but it is not quite suitable for the target audience
of the user's guide and will be rewritten.

A few portions of the texinfo document are simply no longer relevant
and do not need to be migrated.  In particular:
The krb5-appl utilities are out of scope for this document, as they
have been moved to a separate repository.  Coverage of ksu may be
brought back at a later time, though.
The Kerberos Glossary will be expanded and handled separately.

ticket: 7408
Remove make glue for texinfo users guide

Towards removing the texinfo docs entirely.

ticket: 7408
Remove unused texinfo sources

Now that the users guide make rules are removed, some of the texinfo
sources are not referenced from anywhere and can be safely removed.

ticket: 7408
Remove texinfo implementors guide

It is sufficiently old and unloved that nothing in it should be
taken as truth without independent verification.
Content of this nature should live on k5wiki.kerberos.org
in the future.

ticket: 7408
Add an input ccache get_init_creds option

Add a krb5_get_init_creds_opt_set_in_ccache() function.  An input
ccache may hold configuration data which the client libraries can
use to influence their decisions.
Add "pa_type" configuration to ccaches

* When producing preauth data, keep track of the type of padata in the
  KDC's list of acceptable types which prompted the module to produce
  padata.
* After obtaining credentials, store that value as a "pa_type"
  configuration item in the out_ccache.
* Read that allowed preauth type from an in_ccache, if possible.
* If we have an allowed preauth type, only call "real" modules that
  handle that value when filling in responder items and producing a
  client request.
Test in_ccache and pa_types functionality

* Add a krb5int_build_conf_principals() function to allow our get/set
  code to directly prune out duplicate config entries.
* Verify that when we specify a pa_type, it affects whether or not we
  will use a particular preauth plugin.
* Verify that we correctly save the KDC's preauth type number, that we
  tried to answer, to the out_ccache.
Add "pa_config_data" configuration to ccaches

* Read a "pa_config_data" item from an in_ccache, if provided, and add a
  callback which client preauth plugins can use to retrieve a string
  value from it that's keyed by a string.
* Add a callback which client preauth plugins can use to provide string
  key/value pairs to be stored in the ccache.
Use config storage for client identity selection

* Keep track of the names of client identities when we load them.
* Store the client identity we just used when we create or retry a
  client request.
* If we read a client identity from the configuration, treat it like the
  KDC does: pick the "this is it, there is no other" logic branch.
Use config storage for client OTP token selection

* Save the vendor name of the token we used to create the challenge.
* If we saved the name of a token vendor previously, prune out any
  tokeninfos which contain different vendor names.