Receiver should be validated/processed before arguments

[gibson042]

Related to but distinct from #2289, observable interactions with arguments should take place in order (cf. #2377 (comment) ) after validation and processing of the receiver. This is violated by at least the with methods, which invoke PrepareTemporalFields on the first argument before the receiver (observable in code that e.g. defines getters on the receiver like (i => Object.defineProperties(Temporal.PlainYearMonth.from("2022-12"), { year: { get:()=>i++ } }).with({ get month(){ return i++; } }))(1), which currently returns 0002-01 rather than 0001-02).

For with methods in particular, I believe the general corrected steps would be

 1. Let _receiver_ be the *this* value.
 1. Perform ? RequireInternalSlot(_receiver_, [[InitializedTemporal<Type>]]).
 1. If Type(_temporalInstanceLike_) is not Object, throw a *TypeError* exception.
 1. Perform ? RejectObjectWithCalendarOrTimeZone(_temporalInstanceLike_).
+1. Set _options_ to ? GetOptionsObject(_options_).
 1. Let _calendar_ be _receiver_.[[Calendar]].
 1. Let _fieldNames_ be ? CalendarFields(_calendar_, « … »).
-1. Let _overrides_ be ? PrepareTemporalFields(_temporalInstanceLike_, _fieldNames_, ~partial~).
-1. Set _options_ to ? GetOptionsObject(_options_).
 1. Let _fields_ be ? PrepareTemporalFields(_receiver_, _fieldNames_, «»).
+1. Let _overrides_ be ? PrepareTemporalFields(_temporalInstanceLike_, _fieldNames_, ~partial~).
 1. Set _fields_ to ? CalendarMergeFields(_calendar_, _fields_, _overrides_).
 1. Set _fields_ to ? PrepareTemporalFields(_fields_, _fieldNames_, «»).
 1. Return ? Calendar<Type>FromFields(_calendar_, _fields_, _options_).

[ptomato]

It could be debatable which order of operations best expresses the design principle, but ultimately I agree with the one you suggested above.

[ptomato]

I audited all of the methods with at least one argument. Aside from with, I found that PlainYearMonth's until and since methods also did PrepareTemporalFields on the argument before the receiver.

I also found that in PlainYearMonth's add and subtract it's possible we'd want to move steps 5–7 of AddDurationToOrSubtractDurationFromPlainYearMonth to the beginning. However, you could also interpret the existing steps as follows: first the receiver is validated in the caller (add or subtract), then temporalDurationLike is validated in steps 1–3, options is validated in step 4, and the actual calculation starts in step 5. That's more consistent with Richard's suggestion above, where the actual calculation starts with the call to CalendarFields. So I'm highlighting it as something to think about, but I don't think it needs to be changed.