Allow plugin definition to be aliased

Adding aliases directly to the definitions causes problem with various plugin manager as they need some properties of the definitions when processing it. Changing the IS for a different approach.

It's great to see in code how this could look.

However, as far as I can see none of the weirdness raised in the parent are solved: when requesting a plugin by class you might get an object of a different class. Either because of an alter or because the module author deprecated the original class and created a new one but put the old class name in the class property of the definition. At this point the FQCN is no longer a class name just a different but sometimes confusing unique string.

So perhaps this should be postponed on parent until there's agreement whether that's acceptable?

I don't think the related issue is a parent of this, the discussion is more about the plugin ID itself. But in this, we keep the plugin ID as it is, and introduce an alias, which is new, and we can set a new convention around it without worrying about backward compatibility.

As for the FQCN, using FQCN as a method/function argument doesn't necessarily mean we are requesting an instance of that class. If we take a look at this:

\Drupal::entityTypeManager()->getStorage(\Drupal\node\Entity\Node::class);

We don't want an instance of that class, we want something else.

Using FQCN as an argument means better IDE support which will then improve DX.

This will allow getting the definition by the alias, something like this:

\Drupal::entityTypeManager()->getStorage(\Drupal\node\Entity\Node::class);
\Drupal::entityTypeManager()->getDefinition(\Drupal\node\Entity\Node::class);

I think

\Drupal::entityTypeManager()->getStorage(\Drupal\node\NodeInterface::class);
\Drupal::entityTypeManager()->getDefinition(\Drupal\node\NodeInterface::class);

would be better, because it would not tie the configuration/database to an actual implementation but a contract that these implementations MUST implement.

Yes, this relies on the assumption that a plugin always implement a dedicated contract and we know that not every plugins have these kinds of contracts available... which maybe only means that this aliasing feature could only support those that have these. (This limitation was also raised in a Slack thread by @joachim IIRC).

Most plugins already have a common interface. An interface for each plugin seems too verbose for most and probably ends up being an empty interface.

From what I understand, the concern was raised because there is no way yet to deprecate a plugin and this is an issue for FQCN as plugin ID, not as alias. Alias definition will still have the same plugin ID (eg Entity type with alias Node::class will still have a definition with ID node). Plugin ID will still end up in configurations, alias will always used in code and never in configurations. When a plugin class is deprecated this won't be a problem as long as the class is tagged as @deprecated.