Audit use/structure of data classes

[cartermak]

Inspired by the goal of cleaning up the data classes as much as possible (see #11 and #32), we should audit everywhere they're used, everywhere they aren't but should, and how they're structured.

I'm particularly interested in codifying the difference between the "API" and "client" data classes. My current ideas are:

• "API" data classes should contain exclusively serializable data types so that we don't need any custom (de)serialization defined for those classes. They could use default JSON serialization and go straight into the GQL queries.
• Any custom mapping would happen in the "client" to_api_create and from_api_read methods.
• Only "client" data classes would be exposed as input/return types on AerieClient methods. "API" data classes are only used behind the scenes.
• "API" data classes are then only created/used in cases where we need custom (de)serialization. Otherwise, we can directly use the "client" data class.

[cartermak]

Further thought: we have cases where we want to get either "metadata" (using the term loosely, not literal metadata in Aerie) or the full set of data. For example, we want to be able to either get high-level info about a plan (name, start/end times) or download a full plan. A way to do this in dataclasses would be to have a base class, e.g., AcitivtyPlanSummary, and a full version that inherits, e.g., ActivityPlan(ActivityPlanSummary).