fix(core): kas registry commands UX improvements

[jakedoublev]

1. align flags throughout KAS registry commands (i.e. --public-key should not have different shorthands, --id as -i should be consistent throughout all commands)
2. improve code readability
3. improve CLI e2e coverage of KAS registry CRUD

[jakedoublev]

@dmihalcik-virtru is it accurate that the KAS key pem should not be base64 encoded? That appears to be the case in our x-tests: https://github.com/opentdf/tests/blob/450ca7ffef8656eae765e1b62795a24e860d678b/xtest/conftest.py#L102

[dmihalcik-virtru]

The KAS kas_public_key REST endpoint takes a fmt parameter which can be used to control how it is returned. IIRC it currently maybe handles raw and pkcs8 (or maybe 12 for certs)? Maybe you can do CERTIFICATE or PUBLIC KEY types? We probably should be storing PKCS8 in the database, it probably doesn't matter if they are also pem encoded or not and i could see the value either way (less logic for serving PEM encoded variants, which is what most clients will want - at least until we transition to JWK, but more efficient/more direct to store the ASN.1 binary directly).

[jakedoublev]

Thanks @dmihalcik-virtru. With the underlying structure managed by the platform and the otdfctl CLI as a simple client, it sounds like the solution for now is to not base64 encode the public key of a registered KAS in these CLI e2e tests or examples.