Add new record info data classes

[cx1111]

The first step in separating out the record info from the record object itself.

[cx1111]

No unit tests for this because I need to think more about how these data classes are to be constructed.

[cx1111]

Thought about having a separate class for multi-segment headers but it seemed overkill.

[cx1111]

Open to suggestions about nullability/validation here.

[bemoody]

I have a few thoughts. To start with: are these classes supposed to be a description of the data files, or a description of the data?

Confusion between these two roles is a problem with the existing API. For example: wfdb.rdrecord sets the skew attribute if the signal file is skewed, but Record.wrsamp interprets skew as meaning that the signal array is skewed.

Something else to think about is that the test suite does a lot of checks along the lines of "are these two Record objects identical", when what we really want to ask is "do these two objects contain identical data, despite having been created in different ways?"

I would seriously consider having different classes for signal file info (filename, format, byte offset, block size) versus signal info (the rest of that stuff.)

Nullability: If applications are expected to construct a SignalInfo object then the application shouldn't have to specify a value for samps_per_frame. But when I read a record that has one sample per frame, I want samps_per_frame to be 1, not None, regardless of how it's written in the header file. I don't know if that answers the question or not.

Validation: cautiously, I'd be inclined to validate the data when you try to use it (to write a signal file) and not beforehand, especially since validation can depend on relationships between the fields. On the other hand, it might make sense to do type-checking (distinct from validation) as early as possible.

Multi-segment: a multi-segment header isn't the same type of data as a single-segment header (one contains a list of segments, the other contains a list of signals). But a multi-segment record is the same type of data as a single-segment record (the latter can be treated as a special case of the former, or the former can be transparently extended so it behaves like the latter.) The API should preferably be agnostic to the format. That doesn't answer the question of how the Python objects should be structured, because I think it depends on how these objects are going to be used in the larger API.