Let SPNEGO display mechanism errors

To avoid potential recursion we use a thread local variable that tells
us whether the ancestor was called via spnego_gss_display_name().  If
we detect recursion, we assume that we returned a com_err code like
ENOMEM and call error_message(); in the worst case that will result in
an "Unknown error" message.

[ghudson@mit.edu: Edited comments and commit message; removed an
unneeded line of code.]

ticket: 7045
target_version: 1.12.1
tags: pullup
Test SPNEGO error message in t_s4u.py

Now that #7045 is fixed, we can check for the correct error message
from t_s4u2proxy_krb5 with --spnego.

ticket: 7045
Fix krb5_copy_context

krb5_copy_context has been broken since 1.8 (it broke in r22456)
because k5_copy_etypes crashes on null enctype lists.  Subsequent
additions to the context structure were not reflected in
krb5_copy_context, creating double-free bugs.  Make k5_copy_etypes
handle null input and account for all new fields in krb5_copy_context.
Reported by Arran Cudbard-Bell.

ticket: 7807 (new)
target_version: 1.12.1
tags: pullup
Add a test program for krb5_copy_context

This test program isn't completely proof against the kind of mistakes
we've made with krb5_copy_context in the past, but it at least
exercises krb5_copy_context and can detect some kinds of bugs.

ticket: 7807
Move kprop error explanation into Troubleshooting

The plan is to make Troubleshooting section of the documentation a
one-stop-shop place for all error diagnostics, explanations and possible
solutions.  The relocation of kprop error messages descriptions is part of
this consolidation effort.