Define krillc extensions for showing HSM key details

[ximon18]

In the proof-of-concept krillc show --ca was extended in text output to show the Krill Key Identifier, signer ID and signer name for the identity key, and in JSON output to also show this for key transitions.

E.g.

$ krillc show --ca my_ca 
Name:     first_ca

...

ID cert PEM:
-----BEGIN CERTIFICATE-----
MIID...ulQ=
-----END CERTIFICATE-----
Hash: 7288...8448
Key ID: DEAC46204B5316D804871D2682DE8D1D7E81F265
Signer Name: SoftHSMv2 via PKCS#11
Signer Key ID: 41DFC180E363108DCDD60134FB75BD0E5AC7EA2B

And:

$ krillc show --ca my_ca --format json
{
  "handle": "first_ca",
  "id_cert": {
    "pem": "-----BEGIN CERTIFICATE-----\nMIID...ulQ=\n-----END CERTIFICATE-----\n",
    "hash": "7288...8448",
    "key_id": "DEAC46204B5316D804871D2682DE8D1D7E81F265",
    "signer": {
      "name": "SoftHSMv2 via PKCS#11",
      "key_id": "41DFC180E363108DCDD60134FB75BD0E5AC7EA2B"
    }
  },

And:

      "keys": {
        "roll_new": {
          "new_key": {
            "key_id": "27972C819C4EA2A34D15059301B75DAB510CCCEA",
            "signer": {
              "name": "OpenSSL Signer 2",
              "key_id": "27972C819C4EA2A34D15059301B75DAB510CCCEA"
            },
            "incoming_cert": {
              "cert": "MIIF...tjde",
              "uri": "rsync://testbed.rpki.nlnetlabs.nl/repo/testbed/0/27972C819C4EA2A34D15059301B75DAB510CCCEA.cer",
              "resources": {
                "asn": "AS1818",
                "v4": "10.1.2.0/24",
                "v6": ""
              }
            },
            "request": null
          },
          "active_key": {
            "key_id": "FD468AC396CE0DCE51225B52386239646D60ABE1",
            "signer": {
              "name": "SoftHSMv2 via PKCS#11",
              "key_id": "CDA0368613A573F6CDFDA0E68076A7B16DA4260E"
            },
            "incoming_cert": {

We need to decide if these changes are suitable for release and if any other changes are needed.

[ximon18]

it might also be good to have some way to list the known and configured (not necessarily the same, for example if keys were previously created in a backend which is no longer part of the configuration then we know about that backend and the keys associated with it as well as currently configured backends) signer backends and their current status and possibly also their entire key content, both krill and non-krill.

E.g.

$ krillc signers status
$ krillc signers info --signer <SIGNER NAME>
$ krillc signers test --signer <SIGNER NAME>        <-- overlaps with #572 
$ krillc signers list-keys --signer <SIGNER NAME> [--all]
status