Add new implementation of relative time

[leduyquang753]

(This is part of a set of multiple pull requests looking to overhaul the calculation functions.)

This pull request adds a new relativeTime function that directly takes two date values and outputs a single-unit relative time point, with more robust logic compared to the current implementation.

Accordingly, the logic of the relative time element for the relative format is changed to use the new function.

[leduyquang753]

The failing test in the first check:

 ❌ relative-time > [tense=past] > micro formats years
      AssertionError: expected '11y' to equal '10y'
      + expected - actual
      
      -11y
      +10y
      
      at n4.<anonymous> (test/relative-time.js:531:13)

is caused by the original test using new Date() which makes the result vary according to the time of the year. The related feature is not affected by this pull request.

[keithamus]

The intent of using durations here is to anticipate Temporal becoming part of the web platform.

We calculate the duration of the two dates and return a proxy object for Temporal.Duration, so that we can in turn hope to call round on this duration, to get a single unit duration object, which can then be more easily fed into Intl.RelativeTimeFormat.

The Temporal.Duration#round function is very complex, and so for now we have roundToSingleUnit as a "simplified" version of this function, which provides the minimum viable requirements for this code.

The hope is that, once Temporal is a part of the web platform, we can delete a lot of the delicate date code in this library.

The change in this PR, while reasonable in isolation, steps us further away from this goal of steering toward Temporal.

Having said that I'm sure this PR can be factored such that it maintains this goal. It might be worth looking at the round API to figure out how to change the inputs to relativeTime. Perhaps it is worth taking the functionality of relativeTime and factoring it into roundToSingleUnit?

[leduyquang753]

That makes me question then why an already existing implementation of the round function could not be adopted.

Perhaps it is worth taking the functionality of relativeTime and factoring it into roundToSingleUnit?

Sure, it can be quickly done. Without knowing the Temporal vision I made a new function with a different signature because calculating a duration then calculating back the original date would be a very roundabout thing to do. Perhaps then I will raise this concern to tc39/proposal-temporal.