OvmfPkg: introduce PciCapPciSegmentLib

OvmfPkg: introduce PciCapPciSegmentLib

Add a library class, and a BASE lib instance, that are layered on top of
PciCapLib, and allow clients to plug a PciSegmentLib backend into
PciCapLib, for config space access.

(Side note:

The "MaxDomain" parameter is provided because, in practice, platforms
exist where a PCI Express device may show up on a root bridge such that
the root bridge doesn't support access to extended config space. Earlier
the same issue was handled for MdeModulePkg/PciHostBridgeDxe in commit
014b472053ae3. However, that solution does not apply to the PciSegmentLib
class, because:

(1) The config space accessor functions of the PciSegmentLib class, such
    as PciSegmentReadBuffer(), have no way of informing the caller whether
    access to extended config space actually succeeds.

    (For example, in the UefiPciSegmentLibPciRootBridgeIo instace, which
    could in theory benefit from commit 014b472053ae3, the
    EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL.Pci.Read() status code is explicitly
    ignored, because there's no way for the lib instance to propagate it
    to the PciSegmentLib caller. If the
    EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL.Pci.Read() call fails, then
    DxePciSegmentLibPciRootBridgeIoReadWorker() returns Data with
    indeterminate value.)

(2) There is no *general* way for any firmware platform to provide, or
    use, a PciSegmentLib instance in which access to extended config space
    always succeeds.

In brief, on a platform where config space may be limited to 256 bytes,
access to extended config space through PciSegmentLib may invoke undefined
behavior; therefore PciCapPciSegmentLib must give platforms a way to
prevent such access.)

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>