Groups: consider relation-based event speakers instead of flat post_meta

[bor0]

Flagged by @carstingaxion on #1791: _event_speakers is currently a flat post_meta array of user IDs on the event. This doesn't support per-event roles (e.g. speaker on one event, moderator on another).

Reference: GatherPress's long-standing discussion at GatherPress/gatherpress#872, and their experimental https://github.com/carstingaxion/gatherpress-relations (shadow-source based post-to-post relations with per-relation roles).

Not acting on this now — gatherpress-relations is experimental, not core GatherPress, and the current postmeta approach is sufficient for the initial feature scope. Revisit if/when a relations-based approach lands in GatherPress core.

Acceptance criteria

• No action taken while gatherpress-relations (or an equivalent) remains experimental / outside GatherPress core — this stays open as a tracked-but-deferred item, not closed.
• Periodically re-check GatherPress core / the referenced upstream discussion (Stop CCing support@wordcamp.org for allergy/special accommodation email #872) for movement, since this depends entirely on an external decision.
• If/when revisited: _event_speakers flat postmeta is migrated to the relation-based model with a data migration path for existing events (no silent data loss for events that already have speakers assigned).
• If/when revisited: per-event speaker roles (e.g. speaker vs. moderator) are supported without breaking the current single-role rendering in the event-speakers block.

[bor0]

Also raised independently as #1809 (closed as a duplicate of this one) from the same review thread on #1793.

[bor0]

@mauteri @carstingaxion, any sense of timeline for relation-based speakers/hosts landing in GatherPress core (GatherPress/gatherpress#872)?

If it's not imminent, would piloting gatherpress-relations here make sense, similar to how we're approaching recurring events in #1777 (build/test as a plugin, contribute upstream if it works)?