gss-api: tag RFC 2478 NegTokenInit fields explicitly - #2464

With the rfc2478 feature, NegTokenInit declares its four fields tag_mode = "IMPLICIT". The SPNEGO ASN.1 module is DEFINITIONS EXPLICIT TAGS (RFC 4178 Appendix A and section 4.1; RFC 2478 uses the same encoding), and every other context-tagged field in this crate is EXPLICIT, including NegTokenTarg's (the other half of the rfc2478 CHOICE) and NegTokenInit2's. As a result, NegTokenInit can't decode real tokens:

// The NTLM NegTokenInit from this crate's own InitialContextToken test (lib.rs)
let bytes = hex!("303ca00e300c060a2b06010401823702020aa22a04284e544c4d5353500001…");
gss_api::negotiation::NegTokenInit::from_der(&bytes)
// Err: unexpected ASN.1 DER tag: expected OBJECT IDENTIFIER, got SEQUENCE

The reverse also holds: the only encoding it accepts, and the one it produces, puts the [0] tag in place of the SEQUENCE OF tag (300e a00c 060a…). pyasn1 with the RFC definition rejects that, and decodes the real token above fine.

The fix changes the four tag_modes to EXPLICIT. The default (non-rfc2478) types are untouched.

Test: decode_rfc2478_neg_token_init decodes the NTLM token above, checks mech_types and the NTLMSSP mech token, and re-encodes it byte for byte. It fails on master. The gss-api.yml matrix passed locally: powerset tests on stable and 1.85, thumbv7em/wasm32 powerset build, fmt, clippy.

This PR was produced by AI agents (Claude) and reviewed by me before submission.