feat: add resources and controllers for bare metal infra provider

Introduce the concept of "static" infra providers, e.g., bare-metal infra provider, which manage a static set of machines contrary to the "regular" infra providers.

Add the following resources:
- `infra.Machine`: similar to `MachineRequest`, lives in the `infra-provider` namespace, serving as the input of the owning static provider. It is created in the `MachineController` if there is a SideroLink connection with the static provider ID. Regular flow of `Machine` creation is blocked, until this `infra.Machine` is accepted.
- `infra.MachineStatus`: similar to `MachineRequestStatus`, lives in the `infra-provider` namespace, serving as the output of the owning static provider. Its lifecycle must be bound to the corresponding `infra.Machine`.
- `omni.InfraMachineConfig`: a user-managed resource to mark the `infra.Machine`s as accepted or set their desired power state. The acceptance information is then propagated to the `infra.Machine` resource. A machine which was already accepted cannot be unaccepted (checked by a validation), and this resource can only be removed when the `siderolink.Link` for the matching infra machine is removed.

Additionally:
- Add a reverse GRPC tunnel service to the Omni GRPC server, so that infra providers can establish a reverse tunnel to the Omni instance.
- Expose its client in the Omni client library.

Currently, the tunnel only logs when a connection is opened or closed, but when we have the initial version of the bare-metal infra provider, Omni will be able to reboot machines over this tunnel.

Signed-off-by: Utku Ozdemir <utku.ozdemir@siderolabs.com>