WL#11543: instrument the keyring into performance schema

Currently the keyring data are completely non-transparent to SQL users.
This worklog aims at adding P_S tables to expose the metadata of the keys (key
IDs, key owner), provided that the user has enough privileges to see these. 
When using an external key vault (OKV) it is useful to match the internal key ID 
used by the keyring infrastructure, to the ID that this key is stored in the Key 
Vault.

FR1: Add a Performance Schema table "keyring_keys" in the "performance_schema" 
database.

FR2: Upon successful query of to query "keyring_keys" table, return the list of 
the keys in the active Keyring, showing only the key metadata (internal ID, owner 
and backend ID)

FR3: Implement a component service function (in the plugins that can provide such 
information) to return the external (backend) ID used to store the key in external 
key vaults.

FR4: No key data is going to be exposed in the keyring_keys table. No sensitive 
information about the keys should be exposed, only the IDs of the key (both 
internal and external) and the user are to be shown.

FR5: Existing performance schema authentication will be reused. Only users with 
permissions to query the performance schema can access the keyring_keys table.

HLS1: A new table performance_schema.keyring_keys will be introduced. It will 
display details about the registered keys in the keyring

      CREATE TABLE IF NOT EXISTS keyring_keys
      (
        KEY_ID VARCHAR(255) NOT NULL,
        KEY_OWNER VARCHAR(255),
        BACKEND_KEY_ID VARCHAR(255),
      ) 

HLS2: Existing performance schema authentication will be used

mysql_key_iterator is used to query the list of the keys.
keyring->mysql_key_iterator_init() creates the iterator. 
keyring->mysql_key_iterator_get_key() queries the iterator until there is no more 
data or the iterator gets invalidated upon keyring modification.

If implemented by the active keyring plugin, get_backend_key_id() component 
service function will be used to query the backend ID for each key returned by the 
iterator

The iterator is thread-safe for reading. It is invalidated when the keyring gets 
modified. Consecutive calls to keyring->mysql_key_iterator_get_key() will fail so 
the query will prematurely complete. If a race condition occurs, the concurrent 
query to the keyring performance schema table will return incomplete data. 
Currently there is no way to know that the iterator got invalidated, in order to 
restart the collection of the key information.

A vector of  structures is used to internally hold 
the list of the keys used for the current query.

plugin_foreach() is used to query all the installed keyring plugins. The result 
set will hold a copy of the key information only for one of the installed
keyring plugin(s). The rest of the installed keyring plugins (if any) will be 
ignored. Selecting which of the plugin to be used is undefined and may be random.