[DEPRECATE] Deprecates aliasMethod

[pzuraq]

Deprecates the aliasMethod descriptor, and refactors it to not
use the Descriptor system internall

[rwjblue]

This is a little used function, but it is still public API. Do we need all public API deprecations to go through a deprecation RFC, or should it be based on relative usage?

[pzuraq]

I feel like it's extra overhead for something as small as this, without much extra benefit from the RFC process. Relative usage makes most sense to me, especially when you consider the opposite - a private API that is used throughout the community, for better or worse. High usage would definitely dictate a deprecation RFC for a private API, so miniscule usage for a public API IMO means we can skip the overhead.

[pzuraq]

Alternatively, we could streamline the process for these types of deprecations - Simplified RFC format, can be reviewed and merged without FCP, etc. Maybe create a threshold for usage that triggers requiring a full RFC.

[rwjblue]

Can you update this to add svelte support? Specifically, that means to guard all code that isn't needed when the deprecation is gone (adding to @ember/deprecated-features and using an if).

[rwjblue]

We discussed this at the Ember.js Core Team meeting change today, and are 👍 to move forward without a specific deprecation RFC in scenarios that have very low usage and where we are extremely certain we understand all use cases.

tldr; lets land this (once the svelting work is added)

[rwjblue]

This is wrong (as is COMPONENT_MANAGER_STRING_LOOKUP above) the value should be the version that introduced the deprecation (not the version that will remove it).

It should be (!!'3.9.0')...

[pzuraq]

Ahh, gotcha

[rwjblue]

Thank you @pzuraq!