Fewer CalendarDateAdd/DateUntil calls during day-rounding w/ PlainDate

[arshaw]

To the extent we care about reducing calls to user-code, it's possible to not always get the Calendar's dateAdd and dateUntil if you know your not gonna need it for relative-rounding. The case where I've found it's unnecessarily being called is for when relativeTo is a PlainDate and the largest needed unit is <= day. You don't need to involve the calendar for that.

I've removed the relevant calls from the test262 tests (might not be comprehensive):
Branch: https://github.com/fullcalendar/test262/tree/temporal-fewer-calls-rounding-day-pd
Diff: tc39/test262@main...fullcalendar:test262:temporal-fewer-calls-rounding-day-pd

Affects more than just Duration::round. Affects the since/until methods too.

[ptomato]

There's a tradeoff between complexity in figuring out in advance whether you need to Get the method, and unnecessarily Getting it. For sure at one point #2519 was more complicated in this regard than what it currently is. I think it'd be informative if we could see what the effect on the spec text would be.

[arshaw]

In the current code, the place where this decision should be made is very close to plainDateTimeOrRelativeToWillBeUsed. Not literally using that variable, but making a similar variable very near that position.

After that point in the code, RoundDuration, (BalanceTimeDuration or AdjustRoundedDurationDays), and BalanceDateDurationRelative all expect calendarRecs, but if the refactor that #2792 proposes happens, new functions will be written and it'll lead to a much more natural point at which to short-circuit.

I propose we reassess this issue after further exploring #2792

[ptomato]

After #2826, we can rewrite this to be an editorial change. At that point, none of the test262 tests should be affected. It looks like the only thing that changed in your diff above was user code calls.