Refactor of SimulationOutputTimeStamp

[henricasanova]

TimeStamps (TS) for tasks do automatic "linking" of endpoints (i.e., when a "start" TS is created it is stored in some "pending" list, and when a "completion" or "failure" TS is created that list is searched to match endpoints).

The above design is no applied to other timestamps. For instance, for FileCopy TS the "start" TS is passed to the constructor of the "completion / failure" TS.

Looking at adding TS features (for issue #122), a first step is to apply the same design principle (automatic linking) to ALL time stamps.

One question is: what kind of data structure to keep task of "pending" TS. Clearly a map works, where the key is fully specified the operations (e.g., "whoami"+"source"+"file"). But for file operations there could be collisions between keys, so perhaps an unordered_multimap that includes a date?

[willkoch]

FileRead and FileWrite timestamps have been added.

These are stored in an unordered_multimap with the key being the hash of the pointers for file, the source/destination and the (storage) service.

The plan is to refactor other timestamps into this format (file copy and tasks) to prevent the need to pass timestamps in the messaging or reference the specific timestamp Start when setting timestamp Failure or Completion. This general refactor will only be done after the JSON has been consolidated in #133

[willkoch]

File copy timestamps refactored to same design as tasks and file read/write. This allows the removal of timestamps from messages, no longer need to pass it around, can simply find it when needed using file/source/destination.