Create the header protection cryptor once per key

[rnro]

SecFramerAESGCM.headerProtection computed every mask with one-shot CCCrypt,
which creates and releases a cryptor per call. That is three allocations each
time a packet is sealed or opened, six per packet for a connection that both
sends and receives, and the largest single source of allocations on the QUIC
data path. Header protection uses AES-ECB, which carries no state from one
block to the next, so SecFramerKeys now creates a HeaderProtectionCryptor
when the keys are installed and every packet reuses it.

Creating the cryptors costs a connection pair 48 allocations up front, against
the 39 its handshake packets used to spend, so a connection that does nothing
but handshake pays about 9 more.

Measured on my Mac against main with the package's QUIC benchmark tools.
Allocation counts come from full malloc stack logging, which records every
allocation:

QUICTransfer -size 1200, per message      24.37 -> 18.09
QUICTransfer, per 500 KB transfer       6,187.6 -> 3,597.6
QUICHandshake, per connection           1,947.4 -> 1,955.1
QUICStreamLoad, per stream                111.8 -> 100.2

Wall-clock time comes from running main, this change and the other changes
measured alongside it in a rotating order for 9 rounds, and comparing each run
with main's in the same round. Changes moved paths they do not touch by up to
about 1.3%, so differences that size count as noise. The 500 KB transfers took
2.1% less time and the stream load 4.8% less, faster in all 9 rounds each; the
1,200-byte messages and the handshakes did not change beyond noise.

[agnosticdev]

Thank you Rick!

[agnosticdev]

Yep, for Darwin users this is a nice win!

[rpaulo]

FWIW I did look at this optimization in the past but, because I assumed we were going with CryptoKit, I didn't bother much with it.