feat: add set_boot_override trait method with HttpBootUri support

[chet]

This PR adds a new BootOverride struct and Redfish::set_boot_override trait method that exposes full Redfish Boot override support:

• target -- e.g. (UefiHttp, Hdd, etc...)
• enabled -- e.g. (Once, Continuous, Disabled)
• mode -- e.g. (UEFI, Legacy)
• http_boot_uri -- (an optional ipxe.efi URI, which allows us to override DHCP option 67).

The boot_once/boot_first paths now route through it internally, so existing callers keep their current behavior.

The purpose of this is for upcoming feature work: when http_boot_uri is set together with target = UefiHttp, the BMC pins the boot URL, and the host will UEFI HTTP boot from it without needing DHCP option 67 (which we currently set with carbide-dhcp). When http_boot_uri is None, the firmware falls back to option 67 per the UEFI HTTP Boot specification. The idea is we can start controlling the ipxe.efi boot URL via Redfish and not need to have carbide-dhcp populate it via option 67, reducing depdencencies on carbide-dhcp as the DHCP server.

Vendor support implemented (via standard Boot resource PATCH) for: nvidia_gh200, nvidia_gbx00, nvidia_dpu, nvidia_viking, nvidia_gbswitch, hpe, supermicro, ami.

Returning NotSupported (planned as follow-up PRs) for: dell, lenovo. Both BMCs require a vendor-specific BIOS-attribute path (HttpDev1Uri on iDRAC, XCC equivalent on Lenovo) -- they don't expose the standard Boot.HttpBootUri property.

...and then standard and liteon_powershelf will just stay NotSupported.

It currently returns Result<Option<String>, RedfishError> -- Some(job_id) is reserved for vendors that schedule the change via a BIOS settings job (e.g. future dell + lenovo impls); current vendors apply immediately and return None.

Also fixes a stray trailing space in Systems/{id}/Settings and Systems/{id}/SD URLs across the NVIDIA family vendors.

Tests added.

Signed-off-by: Chet Nichols III chetn@nvidia.com