Augmenters receive inaccurate timestamps

The reason why this wasn't done previously is probably this code:

      // If only one of start and end are displayed, alter accordingly.
      if ($parts['start'] xor $parts['end']) {
        if (in_array('start', $parts)) {
          $end_ts = $start_ts;
        }
        else {
          $start_ts = $end_ts;
        }
      }

The code modifies the timestamps permanently, effecting in all the subsequent contexts in which they are used.

Some of these contexts - like the augmenter - need the original stord timestamps, but some of them probably want these modified timestamps. In my fix here, I have passed the stored timestamps to the augmenter only. Figuring out which other contexts need the stored timestamps and which the modified timestamps is beyond me though, that needs deep understanding of this module.

Fortunately, we don't have to solve that here. What I've done in this MR is a step forward, even if there's more that could be done.

@jonathanshaw I'm on board with passing the normalized $start_ts and $end_ts values into separate parameters so that they can be passed unaltered to the augmenters.

Doing a quick scan of the code, I do also see augmentOutput() called in a number of places we aren't touching here, including:
- SmartDateDailyRangeFormatter
- SmartDateRecurrenceFormatter
- SmartDateDurationFormatter (even though it is officially deprecated)
- SmartDateRecurTrait

Most of these are also using the $item value and end_value, so we should make sure all of them use normalized timestamps before we implement a type hint to enforce an expectation that the start and end passed in will be timestamps.

SmartDateDurationFormatter already passes the timestamps.

As I uderstand it: SmartDateDailyRangeFormatter, SmartDateRecurrenceFormatter and SmartDateRecurTrait all seem to built of top of the smartdate field type, which stores timestamps not iso_8601 strings and so already passes timestamps to the augmenter. And as the files aren't opted in to strict types, we don't need to explcitly cast to integer.

So I think we are ok?