Condition manager should ignore plugins that depend on not installed modules

Problem/Motivation

Commerce provides Condition plugins. The condition plugin manager overrides the processDefinition method of the base plugin manager and adds the following code.

$entity_type_id = $definition['entity_type'];
if (!$this->entityTypeManager->getDefinition($entity_type_id)) {
  throw new PluginException(sprintf('The condition "%s" must specify a valid entity type, "%s" given.', $plugin_id, $entity_type_id));
}

This forces a dependency that is false and unnecessary. For example, the Commerce Product module provides the OrderProduct condition which applies to the Commerce Order entity. If you have the Product module enabled and NOT the Order module, and you request for whatever reason the condition manager to collect the plugin definitions, it will load the OrderProduct plugin definition and an exception will be thrown. In fact, calling getDefinition on the entity type manager will throw an exception before the one intented to be thrown here (at least in Drupal 9) complaining that the commerce_order type does not exist.

Steps to reproduce

On a clean Drupal installation enable the Commerce Product but not the Commerce Order module. Then add any code that requests the definitions from the Commerce Condition plugin manager. For example, add a Condition element to a form.

Proposed resolution

In the example above, the product module does not depend on the order module. All plugin definitions should be collected and the ones that depend on entities that do not exist should be ignored by using the getFilteredDefinitions method to get only the plugins for the desired entity types, like the Condition render element does. We should simply remove the piece of code above that enforces the entity type to exist.