feat: Introduce namespaced SEV custom data

[frankdavid]

This PR adds namespacing to the SEV custom data to prevent attestation reports from being reused across different contexts. Previously it was possible to generate an attestation report for one use case and then use it in another.

For example, during a GuestOS upgrade, the Guest VM running the new GuestOS version has to prove that it's running a blessed GuestOS version in order to get the disk encryption key, which it does by generating an attestation report with a specific custom data field in the attestation report. Without namespacing, the upgrade VM can use the remote attestation endpoint of the old Guest VM to generate an attestation report with this specific custom data (this is possible since an attestation report with arbitrary custom data can be requested). This way, the upgrade VM can run arbitrary software since it can take the attestation report from a valid Guest VM. Similar attacks can be constructed in other scenarios whenever an attestation report leaves the Guest VM.

Namespaced custom data ensures that use cases are separated. An attestation report generated for remote attestation cannot be used during upgrades since the namespaces are different.

Custom data now consists of:

| namespace (4 bytes) |           unused (28 bytes)           |                     data (32 bytes)                     |

Namespaces are arbitrary 4 bytes which for convenience we represent as SevCustomDataNamespace.

The remote attestation endpoint now only takes 32-byte inputs and prefixes the custom data in the attestion report with [1, 0, 0, 0].

Types that can be used as custom data via DER-encoding (currently only GetDiskEncryptionKeyTokenCustomData) were previously encoded by
SHA512(DER(object)). These are now encoded using namespace || [0; 28] || SHA256(DER(object))

For backwards compatibility, GetDiskEncryptionKeyTokenCustomData will still be encoded with the legacy encoding so that we can upgrade once. The attestation report verifier code accepts both encodings for GetDiskEncryptionKeyTokenCustomData. New types are encoded with the new encoding.

There will be two more steps of this migration:

1. Once all GuestOS-s accept the new encoding (i.e. they contain this PR), the generation code will be moved to the new encoding for all types.
2. Once all GuestOS-s generate the new encoding (i.e. they contain (1)), the verification code will only accept the new encoding.

The PR also adds tests to the previously poorly tested remote attestation service.