make Plugin::build consume the plugin

[blunted2night]

This patch makes the build method of the Plugin trait consume the plugin. This allows the plugin to transport non-clone-able configuration data into the build process of the plugin. Because this changes a core trait, it ends up touching a-lot, but in the vast majority of cases the change is just removing a & from self in the build method. It will break most users too, but the fix should in most if not all cases should just be removal of the & from self in the build method. It also changes the signature of the dynamically loaded plugin factory function slightly.

The relevant changes, those not just fixing the signature, are in "crates/bevy_app/src/plugin.rs" and "crates/bevy_app/src/plugin_group.rs".

There are two instances in the existing code base that utilized the plugin to transport data into the build process, the PrintDiagnosticsPlugin and the example PrintMessagePlugin which no longer needed to clone the data and can instead just transfer ownership.

My use case for this a precursor for one last alternate approach to overriding the AssetIo instance used in the AssetServer. With this in place, it would be possible to implement overriding the AssetIo like so:

use bevy::asset::AssetPlugin;

app.add_plugins_with(DefaultPlugins, |group| {
    group
        .disable::<AssetPlugin>()
        .add_after::<AssetPlugin, _>(AssetPlugin::with_io (CustomAssetIo))
});

This patch is necessary for this approach to work since AssetIo does not, and should not, in my opinion, implement Clone.

I don't know what future plans may be in store for the plugin system, so this might be taking things in the wrong direction.

[cart]

I think I'll hold off on merging this for a bit because I'm not quite sure I want plugins to be "one time use". Right now they serve as "re-usable arbitrary app initializers". We don't use that property today, but there may be a scenario where its desirable (ex: editors / dynamic plugins / multiple identical app instances / etc). It also sort of goes against the pattern of "configuring plugins via resources".

Is the solution we came to in #1037 a suitable middle ground in the interim?

app
    .add_resource(AssetServer::new(CustomAssetIo, task_pool))
    .add_plugins(DefaultPlugins) 

[blunted2night]

Yeah, this was just an idea that popped into my head.

[cart]

Cool cool. Yeah the approach in this pr might be the right call. I just want to think a bit about the implications first (which I can't do thoroughly right now).

[cart]

I'm going to close this for now as I don't see much of a reason to break things (and we might want Plugins to be reusable for certain scenarios). We can re-open this if/when the need arises.