Support vendor IP separation in multi-party platform definitions

Problem

Patina's platform definition model assumes all platform code is compiled from source in a single build. This works well when one organization owns the entire stack, but breaks down when multiple parties with different IP constraints need to contribute to the same platform binary.

The concrete scenario driving this:

• OEMs (e.g. Dell) define proprietary platform components, services, and driver logic that they do not want visible to third parties — not as source, and ideally not modifiable at all.
• ODMs (Original Design Manufacturers) build the physical boards and need to customize configuration values (memory manager base addresses, chassis types, serial numbers, thermal limits, etc.) without access to the OEM's proprietary code.
• The same platform definition must work on both TianoCore (via patina-tianocore) and Patina native (via patina_dxe_core) without separate codepaths per backend.

In the traditional EDK2/TianoCore world, this is solved by:

• PCDs (Platform Configuration Database) — typed key-value pairs that ODMs set in VPD/DSC files without touching driver source
• Separate .efi images — each vendor ships a sealed PE/COFF binary, the DXE dispatcher wires them together at boot via protocol GUIDs and DEPEX expressions
• IBV build pipelines — proprietary modules are compiled by the vendor's CI; ODMs submit configuration, not code

Patina intentionally moves away from PCDs and toward a typed component/service/config model. This is a better developer experience, but it removes the separation mechanism that PCDs provided. Currently:

1. Core<P: PlatformInfo> is generic and monomorphized — the platform type must be known at compile time as source, not a precompiled artifact.
2. ComponentInfo is not object-safe — it has a Sized bound and uses generic marker types (Add<'a, Component>), so it can't be erased behind a trait object or binary boundary.
3. Patina's Storage is in-process — services registered by one component are visible to all others within the same binary, but there's no cross-.efi-image service resolution without falling back to UEFI protocol install/locate.
4. Rust has no stable ABI — precompiled .rlib files are tied to the exact compiler version and can't be distributed as sealed artifacts across toolchain boundaries.

The net effect is that there's no supported way for one party to ship sealed platform logic and another party to provide configuration, within Patina's current architecture.

Constraints

Any solution should:

• Preserve Patina's typed service/config model (not regress to untyped PCDs)
• Work identically on TianoCore and Patina native backends
• Avoid changes to patina_dxe_core::Core or PlatformInfo if possible
• Allow the IP-owning vendor to ship an artifact the ODM cannot read or modify
• Allow the ODM to provide configuration without access to the vendor's source
• Scale to platforms with many drivers and many configuration points

Prior exploration

Solutions explored so far and their tradeoffs:

Open questions

1. Should Patina have a first-class concept for "configuration that crosses organizational boundaries" — something between PCDs and today's Config<T>?
2. Is there a way to split ComponentInfo registration so that components/services come from one source and configs come from another, without making the trait object-safe?
3. Could a build-system-level solution (e.g., a Cargo plugin or Patina build tool that manages sealed crate composition) be sufficient, or does the framework itself need to change?
4. Are there other multi-vendor firmware ecosystems (Zephyr, coreboot, etc.) that have solved this in a way that could inform Patina's approach?

Start by tracing Core< P: PlatformInfo >, ComponentInfo, Storage, patina-tianocore, and patina_dxe_core as described in the issue, then compare their registration and configuration boundaries. Done means a documented, implementable design that preserves typed configuration, supports both backends, and provides a sealed vendor artifact with ODM-provided configuration.