Add Time#shift for changing a time instance by calendar units

[straight-shoota]

Based on #6574, only the last two commits are specific to this PR.

The main part of this PR renames Time#add_months to Time#shift and adds arguments for additional calendrical units.
This is copied from Timex.shift/2. An also fitting alternative would be #advance (from Rails' Time.advance).
This method can be used for adding arbitrary amounts of (conceptual) time units and forms a basis for an upcoming Time::DateSpan type (see #6522).

This is partly discussed in #6522 and #4556

Regarding performance, the new #shift is about twice as fast as #add_months for shifting by months/years. The comparison is not really fair though, because #add_months called year, month and day individually which means the rather expensive calculations in year_month_day_day_year are executed three times instead of once. With this simple optimization applied, #shift is still 50% faster than #add_months (probably because it does't go through the calendrical constructor).

Time#add_span is also renamed to Time#shift which is a more fitting name as well and means there are two implementations of Time#shift, one based on elapsed time in seconds, the other on calendrical units.
So now there are two ways for adding a time span to an instance of Time:
time + 2.hours advances by the duration of two hours on the instant time-line (elapsed time) and time.shift hours: 2 advances by two hours in local time (wall clock).

[bew]

time + 2.hours advances by the duration of two hours on the instant time-line (elapsed time) and time.shift hours: 2 advances by two hours in local time (wall clock)

I don't understand the difference between the 2 methods (if there is one), could you give an example showing the difference? Ty

[straight-shoota]

If the wall clock advances by two hours, it shows a time two hours later, but that doesn't mean the elapsed time between both instants also equals to two hours. For example when there is a daylight savings switch in between, they might be apart on the instant time line by the duration of only one hour or even three hours.

[robacarp]

@straight-shoota first off, let me say thank you for tackling so much of the nonsense of time and date management. This is one of the things that can create a quality legacy in a language/stdlib and it can be so helpful.

I believe you're trying to capture the essence of what it means to modify a timestamp by measured time, instead of simply incrementing the digits timestamp as if it was simple math, which I believe is what time + delta does.

If that is the case, the word shift is opaque to me. I think I prefer advance, but in the case where a program is "advancing backwards", I'm less certain.

Either way, thanks for this.

[asterite]

@straight-shoota needs a rebase

[luislavena]

Had a joke/suggestion to rename it to Time#travel instead 🤣

[straight-shoota]

@robacarp Yes, Time#advance is a potential alternative. I think I prefer #shift because it fit's with either direction.

[straight-shoota]

@luislavena I think the time travel metaphor fits better for manipulating the clock (such as timecop.cr).

[RX14]

bump

[straight-shoota]

ping @bcardiff

[straight-shoota]

Rebased and ready to ship.