feat: add KeyManagementClient, KmsRegistry and InMemoryKms

[shangxinli]

Summary

Step 5 of #988. Adds the KMS client interface and the registry that creates one from catalog properties, plus an in-memory client for tests and local development.

• KeyManagementClient (core): wraps and unwraps secret keys with a master key held in a KMS, mirroring Java's interface including the optional in-KMS key generation path. The core library stays free of crypto dependencies — this is an interface only.
• KmsRegistry (core): resolves the catalog's KMS client from the same property names as Java, encryption.kms-type (aws, gcp, azure) or encryption.kms-impl (a name registered with KmsRegistry::Register). Built-in clients register themselves when their library is linked; applications register custom ones before creating catalogs. Returns a null client when neither property is set, so an unencrypted catalog is not an error.
• InMemoryKms (bundle, ICEBERG_ENCRYPTION): master keys held in memory, wire compatible with Java's MemoryMockKMS — AES-GCM wrap under the master key with no AAD. Master keys can also come from catalog properties as encryption.in-memory-kms.key.<id> = Base64.

Stacked on #1030 (step 4), which InMemoryKms uses for the AES-GCM primitives; the first commit here is that PR. Review only the second commit, or wait for #1030 to land.

Java parity

Ported against KeyManagementClient.java and EncryptionUtil.createKmsClient, with MemoryMockKMS / UnitestKMS as the reference for the in-memory client. Deliberate differences, both flagged in the code:

• Java resolves encryption.kms-impl to a class name and instantiates it reflectively. C++ has no reflection, so the registry maps a name to a factory; the property keys and their meaning are unchanged.
• Java accepts a fourth type, aliyun. Support Iceberg table encryption (Java-compatible) #988 scopes the built-in clients to AWS, GCP and Azure, so aliyun is not built in here; the doc comment says to register one and select it through encryption.kms-impl. The type list is otherwise identical.

One behavior is matched on purpose rather than "improved": a property that is present but empty counts as set, as in Java, so a misconfigured catalog fails instead of silently loading with no KMS.

Test plan

• encryption_test passes: registry loads a custom implementation and initializes it with the catalog properties, resolves a built-in type case-insensitively, and rejects setting both type and impl, an unsupported type, an unregistered name, and a present-but-empty value.
• crypto_test passes: InMemoryKms unwraps a key encryption key that Iceberg Java's UnitestKMS wrapped under its keyA master key, which is what makes the Java wire compatibility claim testable rather than a C++ round trip. The same works through KmsRegistry with a Base64 master key supplied as a catalog property.
• cpp20_compatibility_test passes. key_management_client.h is core and unconditional; in_memory_kms.h is bundle plus encryption, so it joins aes_gcm_stream.h behind ICEBERG_PUBLIC_HEADERS_ENCRYPTION.
• pre-commit clean, including the generated public-header check.