Improve "(de)serialization" machinery

> [!NOTE]
> "Serialization" and "deserialization" as used in `phare.serialize` refers to conversion of dataclasses from and to JSON-style dicts (the MessagePack encoding is handled separately already). Ideally we would find a better name to avoid confusion here.

The current implementation does not handle deserialization very well yet and just dumps the payload verbatim into the `ServerMessage.payload` field. We should improve this by checking for known formats and deserializing them (e.g. `InputEvent`).

The main challenge would be figuring out a way to do this without coupling the serialization machinery (`phare.serialize`) too much to the protocol itself. In the [Rust](https://github.com/ProjectLighthouseCAU/lighthouse-rust) and [Swift](https://github.com/ProjectLighthouseCAU/lighthouse-swift) implementations of this API we use an enum with associated values (see [here](https://github.com/ProjectLighthouseCAU/lighthouse-rust/blob/9c68f9e29caefd622498d88906aa0da10140eb18/src/protocol/payload.rs) and [here](https://github.com/ProjectLighthouseCAU/lighthouse-swift/blob/de20cd3a9fe14a71986419858caed835702190c6/Sources/LighthouseProtocol/Protocol.swift#L17-L41)) to model this, perhaps we could [use a `Union`](https://stackoverflow.com/questions/16258553/how-can-i-define-algebraic-data-types-in-python) to emulate this ADT-style approach in Python?