Call field and accessor extra initializer after field/accessor definition on the instance

[pzuraq]

This PR updates the ordering of extra initializers added via the addInitializer context object method.

Prior to this change, all initializers added in this way would run on instantiation, before fields and accessors were defined. This resulted in extra initializers added to fields and accessors being able to run and modify the decorated value before it was fully initialized. The concept of "extra initializers" is that they are meant to perform any final setup that should occur for a given value, so it doesn't make sense for these to run before the value they are setting up has been defined.

Additionally, this solves an issue wherein the order of field/accessor initialized values are the reverse of method decoration values. This currently makes it difficult or impossible to write decorators that can be applied to both methods and fields that contain methods:

// It's not possible to ensure that both `a` and `b` behave the same
class Foo {
  @foo @bar @baz
  a() {
    console.log('test')
  }

  @foo @bar @baz
  b = () => {
    console.log('test')
  }
}

Allowing extra initializers to run in the same order as methods and after the fields have been defined enables them to work on both forms.

[pzuraq]

There was consensus to merge this change at the plenary today, I'll do so as soon as I fix CI (with a deadline of getting that done by next week)

[rbuckton]

These changes should fix the CI errors

[rbuckton]

Suggested change

	1. For each element _initializer_ of _e_.[[ExtraInitializers]], do
	1. For each element _initializer_ of _elementRecord_.[[ExtraInitializers]], do

[rbuckton]

Suggested change

	1. Perform ? Call(_initializer_, _F_).
	1. Perform ? Call(_initializer_, _receiver_).

[rbuckton]

Additionally, this solves an issue wherein the order of field/accessor initialized values are the reverse of method decoration values. This currently makes it difficult or impossible to write decorators that can be applied to both methods and fields that contain methods: [...]

I'm not seeing how the order is affected by this PR. Can you clarify what you mean here? Is this related to the missing algorithm steps to append to [[ExtraInitializers]], or something else? Also, could you provide a code example that illustrates the difference between

 @foo @bar @baz
  a() {
    console.log('test')
  }

and

  @foo @bar @baz
  b = () => {
    console.log('test')
  }

that you are anticipating is solved? Without knowing what @foo, @bar, and @baz do, its hard to determine what the concern is.

If you can link to the issues this is intended to close, that might help. I think tc39/proposal-decorators#513 relates to the first concern stated in the OP, but I can't find additional context for the second concern related to @foo @bar @baz order.

[rbuckton]

This PR doesn't seem to include the algorithm steps that add entries to this list, so it will always be empty.

[pzuraq]

[[ExtraInitializers]] are passed into ApplyDecoratorsToElementDefinition, which then creates a context object which adds the initializers there. The logic there is a bit funky, I think I can clean it up at some point so that decorators always use [[ExtraInitializers]] and we don't have the
_staticMethodExtraInitializers_ and _instanceMethodExtraInitializers_, those were from a bit of an earlier draft before there was much distinction between extra initializers

[JLHwung]

If _e._[[Kind]] is ~accessor~, we should pass in _e_.[[ExtraInitializers]] instead of _staticMethodExtraInitializers_.

Ditto for the _instanceMethodExtraInitializers_ in the next instance elements scan.