Figure out a better API for presenting data from bluetooth characteristics

[MoralCode]

Currently WorkoutSummary data is implemented as an object full of futures, which is a bit hacky and a little messy to look at in the code.

Ideally It would be nice to have a data structure that can:

1. be able to represent all the various data available from an erg (even though this comes in sort of piecemeal due to bluetooth packet size limits, and may not be present at all)
2. be able to be fetched in such a way that allows the same data to come from multiple sources (i.e. the individual characteristics or the multiplexed data when trying to avoid size limits)

Specifically for WorkoutSummaries:

1. be associated with the Workout object used to start the workout or be used to construct a Workout if one is not present
2. be able to represent a workout that may be recorded in memory differently from the one that the piece was started with (in the event that a workout is stopped partway via the buttons on the erg or some other method)

ideally this should also be something thats able to extend to the other types of data (which are also spread across multiple characteristics)

[MoralCode]

This should also probably include all the data for every split/interval in one shot.

[MoralCode]

Current thoughts:

create some kind of central "data feed manager" that centrally manages the different characteristics available and reconciles that with the data the user requests such as to only have the minimum number of notifications possible while maximizing available bandwidth (so using the multiplexed characteristic all the time probably wont be a good idea)

its likely that this feed manager would need to create its own Flutter streams so that it has the ability to swap from one source feed (a dedicated chatacteristic for one or more pieces of data) to the multiplexed feed without the application on the other side being aware (they just keep getting the same objects)