cycle time handling and asynchronous tasks

[hjoliver]

Internal handling of cycle times is still a bit of a mess. In the early days, cycle times were simply strings, "YYYYMMDDHH", and were widely used as such throughout the code. Then two complicating things happened:

1. cycle times became objects with the ability to do some date time arithmetic and to check the validity of their initial date time values. But much of the code that uses them still expects the old string form so there's some messy on-the-fly conversion ... this could be cleaned up. [Edit: task cycle times as still string labels, but a cycle time class is used on-the-fly for date time arithmetic]

2. asynchronous tasks with an integer tag instead of a cycle time were bolted on to the system. These tags fail cycle time validity tests so we have to be careful to exclude asynchronous tasks from operations that treat them as if they were cycling tasks. Else: Fixed reload of async tasks in mixed suites, and sequential tasks. #637 Future trigger final-cycle check should ignore async tasks. #649

The big upcoming ISO time change will involve a complete overhaul of cycle time handling. We need to ensure that asynchronous and cycling tasks can be handled cleanly without special case tests that can easily be forgotten. The cycle time class(es) should be able to manage the differences in behaviour automatically.

[hjoliver]

Closing this, it is being addressed with #119.