Remove DEBUG_ERROR_LOCATIONS support

It wasn't being used and it added too much complexity to the
error-handling functions.
Define k5_setmsg internal alias

This is just a shorter internal name for krb5_set_error_message.  The
full name is so long that we have to wrap error messages more than
we'd like.
Use k5_setmsg

Replace most calls to krb5_set_error_message with k5_setmsg for
brevity.  Leave alone plugin sources where we don't include k5-int.h
(mostly PKINIT).
Always include salt in LDAP KrbKey encoding

In the LDAP KDB module, ensure that every krb5_key_data we pass to
asn1_encode_sequence_of_keys includes a salt type, for compatibility
with the decoder in unpatched krb5 1.11 and 1.12.

This is not a behavior change by itself; since 1.7 the encoder has
always included a KrbKey salt field because it erroneously treats that
field as non-optional.  (Luckily, the encoded salt always happens to
have salt type 0 because krb5_key_data constructors start with zeroed
memory.)  The next commit will fix the encoder and decoder to properly
treat the KrbKey salt field as optional, so we need this change to
ensure that our encodings remain compatible.

Also fix the ASN.1 tests to set key_data_ver correctly for the sample
test key data.

ticket: 7919
Treat LDAP KrbKey salt field as optional

Per the ASN.1 definition, the KrbKey salt field is optional.  Since
1.7, we have been treating it as mandatory in the encoder; since 1.11,
we have been treating it as mandatory in the decoder.  Mostly by luck,
we have been encoding a salt type of 0 when key_data_ver is 1, but we
really should not be looking at key_data_type[1] or key_data_length[1]
in this situation.  Treat the salt field as optional in the encoder
and decoder.  Although the previous commit ensures that we continue to
always encode a salt (without any dangerous assumptions about
krb5_key_data constructors), this change will allow us to decode key
data encoded by 1.6 without salt fields.

This also fixes issue #7918, by properly setting key_data_ver to 2 if
a salt type but no salt value is present.  It is difficult to get the
decoder to actually assign 2 to key_data_ver just because the salt
field is there, so take care of that in asn1_decode_sequence_of_keys.

Adjust kdbtest.c to match the new behavior by setting key_data_ver to
2 in both test keys.

ticket: 7919
target_version: 1.12.2
tags: pullup
In KDC, log client principal in bad header ticket

Fix KDC logging to include client principal in TGS_REQ logging even
during error conditions such as "Ticket expired".  As long as the
TGS_REQ can be decrypted and the client principal is available, it
should be included in the log, regardless of other errors which might
be detected.

krb5_rd_req_decoded and krb5_rd_req_decoded_anyflag (not public
interfaces) now leave the decrypted ticket in req->ticket->enc_part2
on success or failure, if the ticket was successfully decrypted.  This
does not affect the behavior of krb5_rd_req.

[ghudson@mit.edu: removed extraneous change, added commit message
summary and description of internal API change, fixed possible memory
leak, removed comment and #if 0 code block of purely historical
interest]

ticket: 7910
Add test for KDC client logging

Add a test case which performed a TGS request with an expired ticket
and checks that the client principal is logged.

ticket: 7910