[rom, rom_ext] Incorporate secure boot verification key type in key manager derivations

@timothytrippel is already working on this.

Since Sep 1, 2023.

### Description

This is a follow up to #7652.

The key manager supports two derivation chains, one for sealing and one for attestation. The attestation chain is expected to meet DICE requirements, thus forcing the key to change based on the secure boot measurements. The sealing key derivation, on the other hand, is expected to be stable and support the ability to apply key versions for anti rollback protection (see keymgr spec for more details).

# Binding value configuration

Currently, the code signing manifest supports a `binding_value` field that can be used to configure the sealing key derivation. In the following table the prefix to `binding_value` defines which manifest is used as the data source for each boot stage:

Binding Registers | ROM | ROM_EXT | Silicon Owner stage (e.g. BL0)
-|-|-|-
`SEALING_SW_BINDING_{0-7}` | ROM_EXT.binding_value |BL0.binding_value | Next stage.binding_value

# Sub key domain priming

Some Silicon Owner will want to have the ability to prime the key ladder based on the key being used. For example, they may want to provisioning a key code signing key for `PRODUCTION`, one for `STAGING` and one for `DEBUG`. These keys are referred to as key subdomains in the context of this issue.

With the current implementation, the code signing tool needs to be aware of the key sub-domains, and apply any necessary priming restrictions to the `binding_value` based on the key being used. This can potentially create a security gap as the key sub-domain is not directly managed by the secure boot implementation with respect to the key manager configuration.

# RFC

* Implement a mechanism to provide mixing of the key sub-domain into the `SEALING_SW_BINDING` configuration for the key manager.
* Decide if this mechanism needs to be supported for the `ROM` as well. It should not be needed as long as the `ROM_EXT` is guaranteed not to require key sub-domain separation.