Deprecating krb5_octet_data and krb5_typed_data

[ghudson@MIT.EDU]

krb5_octet_data was added when PKINIT was merged and is only used by
PKINIT.  It differs from krb5_data in that it uses an unsigned char
pointer.  It continues to be only used by PKINIT (and associated
encoders).  I find it awkward because (1) you can't use any of the
krb5_data helpers with it, and (2) we use krb5_data with unsigned
characters all the time (e.g. in the crypto library), so having a
separate krb5_octet_data presents a schizophrenia over how much we
dislike casting between char * and unsigned char *.

I would like to switch to using krb5_data everywhere we currently use
krb5_octet_data.  krb5_octet_data and krb5_free_octet_data would
remain with deprecation comments.

(I know that using void * in krb5_data would be an improvement if we
had a time machine, but breaking the libkrb5 API is not currently on
the table.)

---

krb5_typed_data was also added with PKINIT and is only used by PKINIT.
It was initially not part of krb5.hin, but was moved there for obscure
(but valid) reasons.  Although typed-data is specified in RFC 4120,
more recent standards such as RFC 6113 effectively deprecate it in
favor of pa-data.  Having the krb5_typed_data type around is awkward
for the same reason as krb5_octet_data; it has the same internal
structure as krb5_pa_data but you can't use the same helper functions
with it.

I would like to use the krb5_pa_data structure everywhere we use the
krb5_typed_data structure.  We would still have ASN.1 encoding and
decoding functions for typed-data, but they would use krb5_pa_data as
the C type.  krb5_typed_data would remain in krb5.hin with a
deprecation comment.

---

I don't expect either of these to be controversial, but I'm checking
before taking unilateral action since both changes would touch a lot
of lines of code.