Ability to provide bootstrap configuration like KBS address, certificates, agent policies etc as pod annotation.

Ref: https://github.com/confidential-containers/cloud-api-adaptor/blob/main/src/cloud-api-adaptor/docs/initdata.md

Scope estimate:

• Creating an InitData file - new procedure module
• Applying as global config - probably by updating the KbsConfig CR
• Applying local config - Adding a notation to the pod (would be a good idea to add this module to CoCo)
• Creating attestation policy for initdata - If changes are small, add callouts to current policy section. If changes are major, reuse existing module for new policy procedure.

These changes will affect Microsoft and IBM. No need to create separate ticket for IBM as long as the changes are targeted for both Azure and IBM.

Wainer's comment in KATA-3426:

The initdata for Peer Pods was introduced in https://github.com/confidential-containers/cloud-api-adaptor/pull/2006

This has direct impact on OSC as the AA_KBC_PARAMS is no longer read from the peer-pods-cm configMap, instead AA_KBC_PARAMS is spread in several fields in the initdata. We will need to change the OSC documentation and deal with upgrade from 1.7.

The initdata is remote attested (which is a good measure) and can be set in two ways:

• Via global variable (INITDATA) in peer-pods-cm
• Via pod annotation (io.katacontainers.config.runtime.cc_init_data)

From documentation point of view, we will need to teach users to:

• Create a initdata file
• Pass it as a global configuration and/or per-pod via annotation
• As initdata is attested, instruct how to create the attestation policy at Trustee 

As it concerns upgrade from 1.7:

• The INITDATA field in peer-pods-cm should be set. In particular, it should read the current AA_KBC_PARAMS to proper populate initdata
• KBS should be updated with attestation policy for initdata. Won't it be a problem for automatic upgrade?