Define how credential metadata "layers" override each other

There are currently multiple ways to get credential metadata for a credential. #721 adds another one.

We should explicitly define the rules for how these sources override each other.

@c2bo posted a comment in #721 with his view:

They way I'd see metadata is in sort of a hierarchy:

• Issuer metadata: most general form level of metadata
• Optional format-specific metadata
• Metadata returned in Credential response

Where Issuer metadata is the default, gets overwritten by format-specific metadata if it exists (only for the values it contains), gets overwritten by credential response (only values that exist in the credential response)

From an implementation perspective:

• Take everything from the issuer metadata
• Check for format-specific metadata and for each value found, overwrite your current metadata construct
• Check Credential Response and for each value found, overwrite your current metadata construct

There was a session partially covering this at IIW. We came to the following conclusions (though feel free to debate):

• It makes sense to allow adding new keys in the metadata
• It probably does not make sense to allow deleting keys in the metadata
• We need to define rules for how/when to recursively go through keys to allow partial overrides
• We need to define rules for how to override arrays

Start by reading issue #721, the metadata hierarchy comment quoted here, and the conclusions from the IIW session. Define agreed rules for adding keys, deleting keys, recursive partial overrides, and array overrides across issuer, format-specific, and credential-response metadata; done means the precedence behavior is explicitly settled.