Improve abstraction for data collections (e.g. Output)

[liamhuber]

We want to group certain pieces of data together in physically meaningful ways; currently this is already done for interfacing to output parsers in shared.output. The motivation is that this lets us define shared language for the same properties, sort of a proto-ontology. Per the discussion at the meeting today, we want to improve the abstraction of this piece of the code. A solutions should:

• Document intention and the "why" of the abstraction
• Minimize the amount of maintenance required if we want to change behaviour (modify one class instead of 20)
• Include meaningful type hints about the final data
• Balance brevity and complexity
  • E.g., exploiting a metaclass is probably too high a barrier for new devs to contribute
  • E.g., ideally the syntax should allow each entry to be a single line
• Be extensible
  • e.g. in case we want to package input data in a similar way
  • e.g. in case we want to add ontological or units information in addition to type hints

Existing attacks (dataclasses, traitlets, pydantic) should be kept in mind.

I'll take a crack at this, but the earliest I'll get to it is a week from today.

A solution to this will close #168 and might close #169.

[liamhuber]

(Elements of) existing attacks: #176, #174, #167

[jan-janssen]

(Elements of) existing attacks: #180, #174, #167

I guess you mean #176 rather than #180

[liamhuber]

I'll take a crack at this, but the earliest I'll get to it is a week from today.

I had intended that my earliest time of attack would be the actual time, but I won't be able to deal with this today; possibly next week.

At a high level, I'm optimistic that an approach identical or similar to the modified dataclass by @JNmpi here will be applicable.