Move rules_ban plugins back into Rules core

Some conditions and actions that depend on the optional core "ban" module were moved into their own "rules_ban" module a while back because we did not want to force a dependency on the core "ban" module. Providing these plugins in a "rules_ban" submodule allowed sites to use these plugins if and only if the core "ban" module was enabled, but did not force all sites to enable "ban" as a precondition to using Rules. This is the way dependencies have always been handled in Drupal, but it is not ideal because we have to manage submodules and make people aware of the additional features in the submodules - if you have "ban" enabled, you have to just know that you should also enable "rules_ban", and you might not even know this submodule exists ... This is an awkward and inefficient mechanism.

It turns out that an alternate solution for this has been available in core since 2014, although it is undocumented, unused, and largely unknown. The solution is described in the change notice: Plugins can depend on a module

This is a feature added to the DefaultPluginManager in order to allow plugins to declare a dependency on one (and only one) module. This only works for plugins that use a plugin manager derived from DefaultPluginManager. Because that is true of the ConditionManager, this feature will work for Rules @Condition plugins, and because that is true of the RulesActionManager, this feature will also work for @RulesAction plugins. In fact, it will work will ALL plugin types defined by Rules because all plugin managers in Rules are derived from DefaultPluginManager.

In the specific case of "rules_ban", instead of putting the condition and action plugins that depend on core "ban" into a submodule, we can add the key/value provider = "ban" to the annotation of these condition and action plugins. When discovering plugins, the plugin manager will examine this key. If the module specified in the value ("ban" in this case) is not available, the plugin manager will not try to load the plugin. This solves the issue of having the plugins available/used only when the core "ban" module is enabled, without us having to maintain a submodule. Similarly, it allows users to have immediate access to these plugins as soon as (and only if) the "ban" module is enabled. Thus users don't have to know about the submodule and don't have to enable it, they will just get access to all the conditions and actions that are usable without having to do anything extra.

The only hitch in doing this was I had to change the RulesIntegrationTestBase because it mock the module handler. When specifying "provider" in the annotation, the DefaultPluginManager will use the module handler to look up the module specified in the "provider". Thus, the mock needs to be able to return a valid value in the case where the "provider" module is not enabled for the test.