Add boot-from-volume support to server controller

[eshulman2]

Add support for booting servers from Cinder volumes instead of images.
This enables the boot-from-volume (BFV) pattern where a bootable volume
(created from an image) is used as the root disk.

Design decisions:

1. Boot volume vs data volumes separation:

   • Only the boot volume (bootVolume field) is attached at server creation
     time via Nova's block device mapping
   • Additional data volumes continue to use the existing dynamic attachment
     mechanism (spec.resource.volumes) which attaches volumes after server
     creation
   • This separation allows data volumes to remain mutable (add/remove after
     server creation) while the boot volume is immutable
   • Avoids duplicating volume attachment logic between creation-time and
     runtime mechanisms

2. No deleteOnTermination option:

   • Deliberately not exposing Nova's delete_on_termination flag
   • If enabled, Nova would delete the underlying OpenStack volume when the
     server is deleted, but the ORC Volume resource would remain as an orphan
   • The orphaned Volume resource would then attempt to recreate the volume,
     leading to unexpected behavior
   • Users who want the volume deleted should delete both Server and Volume
     resources, maintaining consistent ORC resource lifecycle management

API Changes:

• Add ServerBootVolumeSpec type with volumeRef and optional tag fields
• Add bootVolume field to ServerResourceSpec (mutually exclusive with imageRef)
• Make imageRef optional (pointer) with CEL validation

Controller Changes:

• Add bootVolumeDependency with deletion guard and unique controller name
• Handle boot-from-volume in CreateResource by building BlockDevice list

Tests & Examples:

• Add kuttl test for server boot-from-volume scenario
• Add config/samples/openstack_v1alpha1_server_boot_from_volume.yaml
• Add examples/bases/boot-from-volume/ with volume and server examples

depends on #633

assisted-by: claude