Add timeline determination and validation logic

[maarten-ic]

This PR introduces a timeline determination and static checker to ymmsl.v0_2.

TODO:

• Check which parts of the TimelineTree / TimelineNode API should be public (based on the needs of ymmsl2svg)
• Improve error messages
• Add documentation

---

The main idea behind this PR is that all timelines in a model form a tree (the TimelineTree) with the root timeline (":") as root of the tree.

Each component "lives" in a certain timeline, which is also the timeline of their F_INIT and O_F ports. O_I and S ports belong to a sub-timeline of the component's timeline: <component_timeline>:<port_timeline> (according to the timeline annotation in the yMMSL ports definition).

What this PR does:

1. Introduce the TimelineTree object, with a TimelineNode for each timeline in the model.
2. Add logic to determine the timeline for each component in the model. This may fail if:
   • Components are wired circularly: this is the case when a message on a component's F_INIT port depends in some way on the output produced by this component.
   • Components are wired in such a way that the timelines of incoming F_INIT messages don't agree (disregarding repeater filters).
   • A conduit (connected to an F_INIT port) has too many reducer filters. For example, you cannot add a last conduit filter when the sender is an O_F port in the root timeline.
3. Add a function for additional consistency checks: TimelineTree.check_consistent(). This ensures that all conduits connect to the right timelines. This is more extensive than the consistency during the previous pass:
   • Also check conduits that are sending to an S port. Step 2. only considers conduits connecting to F_INIT ports.
   • Check that conduits with repeater filters are consistent with the other conduits connecting to the F_INIT ports.

Some things to discuss (perhaps):

1. Do you agree with the TimelineTree and TimelineNode class names?
2. I'm not very happy with the module name ymmsl.v0_2.timelines yet, since it feels like I should find the Timeline object here (but instead it's TimelineTree/Node). What do you think?
3. Right now I'm so into the details of the timeline functionality that I find it hard to judge if the error messages are clear (enough) to the average user. Do you think this is a good level of detail/explanation to start with?
   N.B. I've put the error messages and logic for providing details in separate Error classes, to separate that as much as possible from the logic checks themselves.