OvmfPkg: introduce gRootBusesConnectedProtocolGuid
    
    QEMU's ACPI table generator can only create meaningful _CRS objects --
    apertures -- for the root buses if all of the PCI devices behind those
    buses are actively decoding their IO and MMIO resources, at the time of
    the firmware fetching the "etc/table-loader" fw_cfg file. This is not a
    QEMU error; QEMU follows the definition of BARs (which are meaningless
    when decoding is disabled).
    
    Currently we hook up AcpiPlatformDxe to the PCI Bus driver's
    gEfiPciEnumerationCompleteProtocolGuid cue. Unfortunately, when the PCI
    Bus driver installs this protocol, it's *still* not the right time for
    fetching "etc/table-loader": although resources have been allocated and
    BARs have been programmed with them, the PCI Bus driver has also cleared
    IO and MMIO decoding in the command registers of the devices.
    
    Furthermore, we couldn't reenable IO and MMIO decoding temporarily in our
    gEfiPciEnumerationCompleteProtocolGuid callback even if we wanted to,
    because at that time the PCI Bus driver has not produced PciIo instances
    yet.
    
    Our Platform BDSes are responsible for connecting the root bridges, hence
    they know exactly when the PciIo instances become available -- not when
    PCI enumeration completes (signaled by the above protocol), but when the
    ConnectController() calls return.
    
    This is when our Platform BDSes should explicitly cue in AcpiPlatformDxe.
    Then AcpiPlatformDxe can temporarily enable IO and MMIO decoding for all
    devices, while it contacts QEMU for the ACPI payload.
    
    This patch introduces the non-standard protocol that we'll use for
    unleashing AcpiPlatformDxe from or Platform BDSes.
    
    Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Cc: Gerd Hoffmann <kraxel@redhat.com>
    Cc: Jordan Justen <jordan.l.justen@intel.com>
    Cc: Marcel Apfelbaum <marcel@redhat.com>
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Laszlo Ersek <lersek@redhat.com>