[REFACTOR] Removes deprecations and adds usage error messages

[pzuraq]

Removes the error messages for importing @tracked and
setPropertyDidUpdate from @glimmer/component and adds error messages
to the GlimmerComponent class for Ember users. This lets them know that
APIs that exist on the class's types aren't actually available in Ember,
as they only exist for Glimmer.js users.

[rwjblue]

Thanks for working on this! I think we need to change things a small amount for the "hooks". Erroring on access for things like this.element, this.bounds, and this.debugName seems fine, but for didInsertElement and didUpdate we expect the most common usage pattern to not be based on accessing the property but instead to be based on extending the base class with those properties defined.

Can you ensure (and test) that this component throws an error upon being rendered:

class Foo extends Component {
  didInsertElement() {}
}

[pzuraq]

Yeah, I was a bit split on what to do here. This is probably going to be a common enough failure case, where someone defines the hook and expects it to work like it did in Ember, but then it doesn't. However, it also seems like a valid thing to be able to do in general.

For instance, you could imagine someone converting a component to be a Glimmer component, and copying an old didInsertElement over to it, adding @action and @ember/render-modifiers, and calling it a day:

export default MyComponent extends Component {
  @action
  didInsertElement() {
    // do things...
  }
}

<div {{did-insert this.didInsertElement}}></div>

And while that may be somewhat confusing, I would expect it to work in the new paradigm, just knowing how modifiers and actions work. Additionally, it'd be confusing that only didInsertElement and didUpdate would throw messages - what about all the other classic component lifecycle hooks?

I think we could either:

1. Do it on access, as it is currently, which basically disallows attempting to call super (this is basic muscle memory for most Ember devs, so I'd expect it to come up early and often for most folks) and attempting to call the methods manually, if they were not overridden.

2. Do it for all classic lifecycle hooks, disallowing any method name that coincides with a classic hook. That way, we're consistent.

[rwjblue]

I think it is very common to not call super in hooks, and since the framework doesn’t invoke the methods the super call would just never run (and the error would never surface, leaving the dev super confused).

Do it for all classic lifecycle hooks, disallowing any method name that coincides with a classic hook. That way, we're consistent.

This seems fine to me, but the only reason we are reserving these names at all is because the types still mention them. Eventually we want to remove those methods (likely 2.0?), which allows us to remove these errors.

Tldr; I think it’s fine to error only for the specific methods that are problematic, and lint against using any of the hooks without @action.