Added ListGridpoolEnergySchedules and ListMicrogridSensors RPCs

[thomas-nicolai-frequenz]

Summary

This PR extends the Platform Assets API with market-topology and Gridpool-related metadata needed by trading, forecasting, reporting, and operational tooling. The PR also adds Gridpool energy schedules and microgrid sensor listing support.

Changes

• Added ListMarketTopologyRelations for querying market-topology relations within the current enterprise scope.
• Added MarketTopologyRelation as the canonical relation model between Gridpools, Microgrids, and Market Locations.
• Added MarketParticipation and MarketParticipationType to describe use-case-specific participation of a market-topology relation.
• Added ListGridpoolEnergySchedules for retrieving static Gridpool energy schedules.
• Added GridpoolEnergySchedule, including counterparty balancing group, Gridpool and counterparty delivery areas, direction, validity period, cancellation timestamp, delivery duration, and scheduled active-power time series.
• Added GridpoolEnergyScheduleDirection to describe import/export direction from the perspective of the Frequenz balancing group.
• Added ListMicrogridSensors for listing sensors belonging to a specific microgrid.
• Updated service-level documentation to describe both platform asset metadata and market-topology metadata.
• Aligned request filters with the existing nested filter-message pattern used by the API.

Notes

MarketTopologyRelation intentionally supports relations without a Gridpool. These represent Microgrid-to-Market-Location links used for deployment, metering validation, reporting comparison, or local optimization, and do not imply market participation.

If gridpool_id is set on a MarketTopologyRelation, the relation represents participation in a Gridpool context. In that case, delivery_area is required and participations may describe use-case-specific validity.

Gridpool energy schedules use a schedule-level delivery_duration. Each time-series entry contains only a start timestamp and applies until start_time + delivery_duration.

The API does not expose derived active/inactive schedule status. Clients can derive effective status from validity_period, cancel_time, and their own evaluation time.

[cwasicki]

LGTM

[cwasicki]

LGTM