platform-mc: Add entity-type-specific D-Bus inventory interfaces

PldmEntityReq unconditionally inherits Inventory.Item.Board
regardless of the actual PLDM entity type. A GPU terminus therefore
exposes an Inventory.Item.Board interface, making it
indistinguishable from an actual board when bmcweb enumerates the
Redfish Chassis collection via the object mapper.

bmcweb's Chassis aggregation queries the mapper for objects
implementing specific Inventory.Item.* interfaces, and emits the
corresponding Redfish @odata.type (Chassis, Accelerator, Processor,
etc.) based on which interface is found. Today, all PLDM termini
show up as generic Board because that is the only interface
PldmEntityReq implements, regardless of what the device actually
is.

Refactor PldmEntityReq into a class template parameterized by the
sdbusplus Item server type, with a PldmEntityBase abstract base
providing the property setters via the Decorator interfaces
(Asset, AssetTag, Revision, Compatible). A createPldmEntity()
factory function selects the correct template instantiation based
on the PLDM entity type reported by the Entity Auxiliary Names
PDR:

  System Chassis      -> Inventory.Item.Chassis
  Processor           -> Inventory.Item.Cpu
  Memory Module       -> Inventory.Item.Dimm
  Fan                 -> Inventory.Item.Fan
  Power Supply        -> Inventory.Item.PowerSupply
  GPU / Accelerator   -> Inventory.Item.Accelerator
  Board / SysBoard / Card / default -> Inventory.Item.Board

This change deliberately does NOT touch the D-Bus object path
convention. Per OpenBMC conventions (as followed by entity-manager
and other services), D-Bus object paths are opaque identifiers
and should not be parsed or treated as semantic by consumers.
All meaning is carried by the interfaces the object implements,
which is exactly what this change corrects.

The existing /system/board/<name> path prefix is a historical
namespace label matching entity-manager's convention, not a type
claim about the underlying device. A GPU terminus after this
change implements Inventory.Item.Accelerator while living at
/system/board/GPU0, which looks odd in busctl tree but is
correct by the established convention.

Tested: Unit test createPldmEntityTest exercises all 10 entity
type mappings (System Chassis, Processor, Memory Module, Fan,
Power Supply, GPU, Accelerator, Board, SysBoard, Card) plus
unknown-type fallback, verifying each produces a non-null entity
with working property setters through the PldmEntityBase
abstract interface. Docker CI passes (format, build, all unit
tests, 50.6% line coverage). End-to-end on Renode evb-ast2600
with PldmFirmwareDevice (entity type 152/GPU) over MCTP serial
confirms the terminus object at /xyz/openbmc_project/inventory/
system/board/GPU0 implements Inventory.Item.Accelerator (Robot
Framework test ASPEED_PLDM_Inventory: 2/2 passed).

PS7 review feedback (Brad Bishop):
  - Default-construct the move ctor/assignment for PldmEntityBase
    and PldmEntityReq instead of deleting them. Class users should
    be in control of ownership semantics rather than getting the
    deleted-by-default behavior baked in by the inventory layer.
  - Rename the lowercase server-type aliases to CamelCase
    (assetserver -> AssetServer, etc.) per OpenBMC style.

Change-Id: Ia143edef5083a58dbe65864e63f7ede37e5e7594
Signed-off-by: Gary Beihl <garybeihl@microsoft.com>