Opaque/On-Demand Data

Currently we deliver all available data in events to the user and our types are accordingly composed: pub struct Data { pub data_1: ..., ... }. However sometimes users just don't need all the data and especially when we implement #99 a lot of data (number of things, not size) has to be assembled by the backend.

This can sometimes involve multiple callback per field which might be computationally expensive if the user doesn't need all the information.
This proposal aims to reduce the impact of this issue by turning delivered events into opaque types where users can query the data they need individually.

The opaque type will most likely have to carry some state with it that will come with a lifetime, so the data can probably not be transferred to a different thread or out of the event loop in a complete package. This will further increase the cost of moving to the trait-based system and the elimination of the Event type.

Most likely it would make much more sense to discuss/implement this proposal when we have fully switched to the trait-based system and Event/WindowEvent doesn't exist anymore.

Start by reviewing the current Event and WindowEvent types and the proposed trait-based system, including the dependency on issue #99. Compare how event data is currently assembled with the proposed opaque, on-demand access model. Done would require an agreed design for the API, state and lifetime handling, and thread-transfer behavior.