Increase Patina GUID Usage [Rebase & FF]

[makubacki]

Description

A series of commits to increase adoption of Patina GUID types in the codebase.

---

sdk: Make BinaryGuid::from_bytes() const

This function wraps efi::Guid::from_bytes() which is const. It is
made const as well.

---

BinaryGuid: Derive Ord and PartialOrd

Add Ord and PartialOrd derives to BinaryGuid, enabling its use as a
BTreeMap key.

Adds a test to verify BinaryGuid's derived ordering matches Guid<'a>'s
byte-order comparison for a set of GUID pairs.

---

guid: Convert GUID types to BinaryGuid

Resolves #1105

Converts all GUID constants, trait associated types, struct fields,
and other uses to Patina GUID types across the codebase.

Key changes:

• GUID constants mostly use BinaryGuid::from_string() since strings
  are more readable than fields. In some cases, a field may have been
  a simple numbering sequence like "123456...", in which case it may
  have been left as from_fields.
• Changed ProtocolInterface::PROTOCOL_GUID changed to use
  BinaryGuid, eliminating duplicated GUID values in implementations.
• Updated FromHob::HOB_GUID and HobParsers BTreeMap key to
  BinaryGuid.
• Updated #[repr(C)] struct fields (GuidHob, FV/FFS headers,
  MM communicate header) to use BinaryGuid since it provides
  binary-compatible GUID storage.
• Updated the FromHob proc macro to use BinaryGuid::from_string().
• Updated a lot of code to use Patina GUID types instead of the r-efi
  GUID type.

There were a few places, particularly in UEFI Spec FFI interfaces,
where the efi::Guid type is still used. This is intentional to
potentially simplify the r-efi 6.0.0 integration. In code that
interacts with those interfaces, From and Into functions are used
to simply convert between BinaryGuid and efi::Guid. Some code
that exclusively interacts with those interfaces, might also use
efi::Guid for local GUID definitions instead of Patina GUID types.

---

• Impacts functionality?
• Impacts security?
• Breaking change?
• Includes tests?
• Includes documentation?

How This Was Tested

• cargo make all
• patina-qemu Q35 and SBSA boot to EFI shell
• Tested boot to Windows on a physical Intel platform

Integration Instructions

• N/A - Patina refactor

[patina-automation]

✅ QEMU Validation Passed

All QEMU validation jobs completed successfully.

Note: Windows Q35 is only built (QEMU boot is disabled due to QEMU vfat issue).

Workflow run: https://github.com/OpenDevicePartnership/patina/actions/runs/23165210991

Boot Time to EFI Shell

Platform	Elapsed
Linux Q35	43.4s
Linux SBSA	40.8s

This comment was automatically generated by the Patina QEMU PR Validation Post workflow.

[codecov]

Codecov Report

❌ Patch coverage is 86.66667% with 16 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
patina_dxe_core/src/allocator.rs	28.57%	5 Missing ⚠️
patina_dxe_core/src/misc_boot_services.rs	62.50%	3 Missing ⚠️
patina_dxe_core/src/runtime.rs	0.00%	3 Missing ⚠️
patina_dxe_core/src/pi_dispatcher/image.rs	60.00%	2 Missing ⚠️
patina_dxe_core/src/events.rs	50.00%	1 Missing ⚠️
patina_dxe_core/src/pi_dispatcher/fv.rs	85.71%	1 Missing ⚠️
sdk/patina/src/pi/fw_fs.rs	66.67%	1 Missing ⚠️

📢 Thoughts on this report? Let us know!

[makubacki]

Note: Patina QEMU PR Validation boot failure is expected until a patina-qemu release that fixes the issue described in OpenDevicePartnership/patina-dxe-core-qemu#142 is made.