Bugfix/718

Fix for https://github.com/elm-lang/Elm/issues/718.

The solution to the problem was to add a hook to `elm.timer` so the time delay can be set to a particular value. A clock could continue *at* a certain point. This broke Mario though.

The trouble was that in `time.js` there was:
```
curr = elm.timer.now();
diff = zero ? 0 : curr - prev;
prev = curr;
elm.notify(ticker.id, diff);
```
The `prev` variable held a time that was in the future when the program continued from a point in the past. So now we have to fill that `prev` variable with the time from the previous event.

#### Bug introduced
The events are stored in a sequential array. A new one gets added whenever `elm.notify` is called. So suppose you have an `fps 1` and `fps 120` in the same program, and scrub back in time. When you continue, both timers will get the same value for `prev`. They should get the time associated with the last event *caused by* that timer. Therefore, the value handed to the `fps 1` timer should be smaller (earlier in time) than the previous-time-value handed to `fps 120`.

This will mean a big refactoring of how events are stored. I think we should merge this bugfix in, make a bug report of this, and refactor in response to that bug report. The bug solved by this PR comes up in simple examples but the bug introduced here is harder to find. I'd like to get the most obvious bug squashed first, as opposed to all-at-once.