[occm] Provide alternative way to define floatingIP instead of `spec.loadBalancerIP`

/kind feature

What happened:
Currently in order to specify the floatingIP of a loadbalancer a user has to define:

...
spec:
  loadBalancerIP: 122.122.122.122
...

as documented in the docs. There is no other way to pass which floating-ip to use.

From k8s docs:

Note:
The.spec.loadBalancerIP field for a Service was deprecated in Kubernetes v1.24.
This field was under-specified and its meaning varies across implementations. It also cannot support dual-stack networking. This field may be removed in a future API version.
If you're integrating with a provider that supports specifying the load balancer IP address(es) for a Service via a (provider specific) annotation, you should switch to doing that.
If you are writing code for a load balancer integration with Kubernetes, avoid using this field. You can integrate with Gateway rather than Service, or you can define your own (provider specific) annotations on the Service that specify the equivalent detail.

We hit this issue when migrating from ingress to gateway API (Cilium provider) and there is no way to specify the floating-ip as cilium gateway api implementation ( and i expect more ) do not offer a way to set .spec.loadBalancerIP due to it being deprecated. I suspect this will become more of an issue as gateway gets adopted more and more.

It would be nice to have an alternative way to define which floating ip to use. Annotations can be a way to do that as at least the gateway CRD allows passing annotations to the service of type loadbalancer.

Anything else we need to know?:

• this request probably needs to take into account ipv4 and ipv6 etc
• this has been discussed here but the scope was a bit different i think: https://github.com/kubernetes/cloud-provider-openstack/issues/2443

Start with docs/openstack-cloud-controller-manager/expose-applications-using-loadbalancer-type-service.md, the Kubernetes Service load balancer documentation, and the discussion in issue #2443. Compare how Gateway API implementations pass annotations to LoadBalancer Services and determine the required provider-specific behavior. Done should include a defined alternative that supports the relevant IPv4 and IPv6 cases and is documented.