Let user specify the start-time of the program

[erlingrj]

This PR adds a new command line argument -s --start-time that allows the user to specify the start time of the program. This currently only works for non-federated programs. In a federated setting the program will then wait until the specified start time (if it is in the future) before reaching out to the RTI and negotiating a start time.

Currently there are no tests for this feature, but I have tested it on my end.

[edwardalee]

This looks very useful, but there are two issues:

1. The start time is not a duration, so the usage message and variable names should be updated. It's an absolute start time.
2. It would be useful to have some hints about how to specify a start time. It requires units, but on a POSIX machine, it will be specifying the number of nanoseconds since Jan. 1, 1970. Maybe there is a utility function that will tell me what, say, 2PM today is in seconds?

[erlingrj]

Thanks for your feedback Edward! I have done a couple of changes:

1. Better help message:

  -s, --start-time <time-point> <units> 
   The logical start time of the program, expressed as an absolute time point
   which is the duration since the epoch of the underlying system clock.
   The units are nsec, usec, msec, sec, minute, hour, day, week or the plurals of those.
   On linux, to compute a start time of 2 minutes into the future, expressed in seconds, you can do:.
     `date -d "2 minutes" +%s`.

3. Dont wait for start_time to arrive if fast mode is enabled
4. Refactor the setting and waiting for start time into a function that can be used by both unthreaded and threaded execution