Throw if an initializer would be decorated

[nicolo-ribaudo]

Ref: #177 (comment)

This PR makes it an error to have code like this:

class A {
  @decorator
  @decoratorWhichReplacesTheMethodWithAnInitializer
  foo() {}
}

so that decorators don't have to handle initializers as input (since they can't be created from syntax)

[ljharb]

I’m a bit confused; don’t decorators already have to be able to handle an initializer as input, since you can decorate a public field?

[nicolo-ribaudo]

Since we will change the name of initializers, we shouldn't associate them with fields.
In #177 (comment) Daniel proposed (and noone disagreed) that we should throw if a finisher is passed to a subsequent decorator. For the same reason, we should throw for initializers.

[ljharb]

ahh, gotcha - so you're saying when a decorator would otherwise receive as input a "no-op" descriptor (an initializer/effect/etc), it throws. That makes sense :-) the name "initializer" confused me :-D

[littledan]

We can change the name of initializer in a follow-on patch.

Thanks for this! Not sure why I thought it would be more complicated.