orchestrator: Add the TrialBoot capability trait

Activating an update proposes a boot candidate and never commits it, whether
the eRoT actuates that itself through Updatable::activate or a PLDM firmware
device does it on the eRoT's behalf. Updatable's docs already name TrialBoot
as the gate that resolves the proposal; this is that trait: is_pending,
confirm, revert, no slot ids.

One contract covers both implementors. A passive downstream device is judged
from outside over its boot-complete line; the eRoT's own image is judged by
the boot the trial started, so is_pending has to be answerable from durable
state alone. The arming applies to the next boot only, so an unresolved trial
falls back on its own, but the record stays pending until confirm or revert,
which is how an orchestrator that rebooted mid-update finds it again.

confirm moves slot metadata only. Raising the anti-rollback floor is
SvnFloor::advance and happens later, so revert always has a bootable image to
fall back to.

Assisted-by: Claude