Use dedicated bootstrap-tokens per shoot worker machine (instead of a long-valid shared token)

Background:
When a new node of a shoot cluster is created the kubelet needs to register with the shoot api server. The kubelet uses a bootstrap-token for authentication.

New:
In the proposed new flow the worker controller (here MCM) creates a temporary bootstrap-token for each created vm.
If the featureFlag BootstrapTokenForVMs is enabled a file with the content "<<BOOTSTRAP_TOKEN>>" is added to the operatingsystem-config. It is passed to the worker controller. The worker controller generates a temporary token for every new worker instance(node). It replaces the "<<BOOTSTRAP_TOKEN>>" string with the created token and adds it to the user-data placed on the vm on startup.
The cloud-config-downloader(original user-data) will then refer to the new temporary bootstrap-token in the kubelet-bootstrap script.

See the depicted flow in the following graph:

For old flow see also https://github.com/gardener/gardener/blob/a62e5622facd20d70c069c17bf42947dbea427ef/docs/extensions/operatingsystemconfig.md#how-does-gardener-bootstrap-the-machines

Steps:

Adapt worker controller to add bootstrap-token on vm creation:

• MCM -> merged: Add bootstrap token generation machine-controller-manager#351
• Verify if there are other worker controllers needed to be adapted
• Adapt worker controller contract to include handling bootstrap-token

Test and adapt os-extensions to support passing the <<BOOTSTRAP_TOKEN>> unencoded

• gardenlinux -> Enh/transmit unencoded gardener-extension-os-gardenlinux#29
• suse-chost -> Enh/transmit unencoded gardener-extension-os-suse-chost#41
• ubuntu -> Support TransmitUnencoded flag gardener-extension-os-ubuntu#42
• flatcar -> Support transmitUnencoded flag gardener-extension-os-coreos#24

Adapt g/g code to support new bootstrap-token:

• PR opened: Enh/bootstrap tokens for machines #3902

Next steps:

• release all os-extensions.
• After 3 g/g releases remove support for creating the token the old way and inform the users that with this g/g version a compatible version of the os-extension-provider and the infrastructure-extension is required.

For more information on why roll this out in multiple steps see: #3902 (comment)

How to categorize this issue?
/area security
/kind enhancement
/priority 3