Expose application interface to use partial messages

[lucassaldanha]

Defines and wires the client-facing API (Step 2 of #435).

Scope

• PartialMessagesHandler<PeerState> interface:
  • onIncomingRpc(from, peerStates, rpc) — fast, non-blocking; runs on pubsub event thread.
  • onEmitGossip(topic, groupId, gossipPeers, peerStates) — called during heartbeat for partial-capable lazy-push targets.
• PublishAction<PeerState>(partialMessage?, partsMetadata?, nextPeerState?, error?) — library applies nextPeerState atomically per peer (no in-place map mutation; deliberately different from go-libp2p).
• PublishActionsFn<PeerState> — app-supplied per-publish decision function returning Sequence<Pair<PeerId, PublishAction<PeerState>>>.
• PartialMessagesPeerFeedback side-channel — reportFeedback(topic, peer, USEFUL | INVALID | IGNORED) for driving peer scoring (matches Prysm's pattern).
• GroupState container, not thread-safe, event-loop serialised.
• Builder wiring: GossipRouterBuilder.partialMessagesHandler optional field; null + PARTIAL_MESSAGES flag enabled → build-time error.

Non-goals

• Partial-specific scoring rules (deferred — see Review peer scoring impact of partial messages #447).
• Any application logic for what partsMetadata or groupID mean — fully opaque to the library.
• DoS caps + TTL GC — tracked in Refine DoS protection and other security/performance concerns #449.

Reference

Design: docs/partial-messages.md §4 (lands with the first PR on #435).