Phase end callbacks don't execute at the right time when reverse skipping occurs

### Dependencies

`navigationSkip: true`, `preventReverseSkipping: false`
### Reproduce

Assume all steps transition for 3 seconds. When the user navigates to step 2, then back to step 1 after 1 second, step1 will be reversed but starting from its mid-animate-out position. Because step 1 has transitioned to its animate-out but only for 1 second, it'll only have 1 second to get back to the end of its animate-in position.

The `getStepDurations` functionality currently gets the full time for a steps transition and doesn't account for mid-animation times as described in the above example. This means that step 1 will reach the end of its transition after 1 second but phase end callbacks won't execute until the full transition time has expired (3 seconds).
### ~~Solution 1~~

~~Rely on the `transitionEnd` event instead of determing the maximum length of a steps transition and waiting for it to end.~~

Due to the `transitionEnd` event firing multiple times for each property that transitions on an element, we can't reliably use `transitionEnd` as we can't determine via JavaScript how many of its properties will transition.
### ~~Solution 2~~

~~Reduce the transition total by the amount of time between navigating to step 2, then back to step 1.~~

This would only work for transitions with a timing function of `linear`.
### Solution 3

As per solution 2 but get each element's `transition-timing-function` and change the amount of time between navigation to step 2, then back to step 1 based on the timing function.
### Solution 3

When navigating back to step 1, reset the elements back to their starting position and start them again.

This may be undesirable when `fadeStepWhenSkipped` is disabled as the elements will visually snap back to their starting position.

To work around the snap described above, the elements could be given a negative `transition-delay` the equivalent of the time passed since navigating to step 2, back to step 1. This will force the elements to start at a particular point in their animation and will also respect timing-functions. The only issue with this is that because a lot of DOM changes would need to occur to stop the element transitioning, reset it back to the start, then set it again with a negative `transition-delay`, the snapping described may still briefly occur, especially as the 50ms delay is required to allow the DOM a chance to sequentially apply each of these modifications to the element.