Add advertiseAddress to NetworkProfileSpec for split management/tenant addressing

[bsctl]

New Feature

When Kamaji is used with OVN-based tenant networking, the TCP pod serves two networks:

• the management network (for CAPI controllers)
• the tenant OVN VPC (for workers).

Problem:

A single address cannot satisfy both: setting it to the management ClusterIP makes it unreachable from the OVN VPC, and setting it to the tenant VIP makes it unreachable from the management network.

Proposed Solution

Add an optional advertiseAddress field to NetworkProfileSpec.

When set:

• Tenant-facing outputs use the advertise address: kubeadm-config, cluster-info, admin.conf, konnectivity --proxy-server-host, and kube-apiserver --advertise-address.
• Management-facing outputs remain unchanged: status.controlPlaneEndpoint stays on the management address
• Cert SANs include both addresses
• Backward compatible: when unset, behavior is identical to upstream

This enables OVN relays to present a stable VIP on the tenant network while CAPI continues to reach the TCP via the management network.

To be used with CAPI, similar advertiseAddress field to KamajiControlPlane.Spec.Network (and KCPTemplate) and propagate it to TenantControlPlane.Spec.NetworkProfile.AdvertiseAddress during reconciliation.

[prometherion]

#986 seems trying to resolve exactly this issue

[bsctl]

Thanks for pointing to it, @prometherion!

Seems #986 is solving a quite similar problem: one TCP, two consumer networks needing different addresses but with different scope. If well understand, it lets to use a DNS name instead of a LoadBalancer IP address in kubeconfig, i.e. ControlPlane.Service.PublicAPIServerAddress. But the kubernetes endpoint inside the tenant cluster would still point to the management address that is not reachable from the isolated OVN network.

For our use case, ControlPlane.Service.PublicAPIServerAddress is debatable. We need for advertiseAddress field semantically belongs in NetworkProfile since it's about network addressing, not service type. Also we do not need a refactoring of controller-manager/scheduler.

I'll open a different PR addressing our specific use case, happy to rebase on #986 if it make sense.