Only pre-key one cipher context for direction-independent AEADs (#15614)

* Key a single base context in EvpCipherAead

Previously every EvpCipherAead pre-keyed two contexts, one for
encryption and one for decryption. Most of our AEADs (GCM, ChaCha20-
Poly1305, SIV, GCM-SIV) only use the forward block cipher, so a context
keyed for encryption can be switched to decryption by re-initializing
it with no cipher or key, which we already do per-operation to set the
nonce. Only key one context in that case.

OCB is the exception: OpenSSL picks its hardware stream routine at
key-setup time based on the direction, so flipping a keyed context
yields wrong output. It keeps a separate pre-keyed decryption context.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NMHEsFraACZfyKod2vniDh

* Model AEAD pre-keyed contexts by key schedule kind

Replace the "base context plus optional decryption context" shape with
an explicit KeySchedule enum. A cipher's key setup is either direction
independent (GCM, ChaCha20-Poly1305, SIV, GCM-SIV), in which case one
keyed context serves both directions, or per-direction (OCB), in which
case one context is keyed for each. CCM keeps no pre-keyed contexts.

This makes it clear the single-context case is not an assumption about
which direction is more common.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NMHEsFraACZfyKod2vniDh

* Gate per-direction key schedule on backends that support OCB

OCB is the only cipher with a direction-dependent key schedule, and it
is unsupported on LibreSSL, BoringSSL, and AWS-LC, so the PerDirection
variants were dead code there and failed clippy with -D warnings.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NMHEsFraACZfyKod2vniDh

---------

Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>