Allow reconfiguring a Plugin inside a PluginGroup

[rmsc]

This is a simple change that allows one to reconfigure a plugin inside a PluginGroup. I'm not sure if this is to be allowed or not, but it allows plugin crates to provide their own specialized version of the DefaultPlugins.

A good use case would be if a Plugin requires some change to the BaseRenderGraphConfig, but would otherwise play nice with the rest of the DefaultPlugins.

To illustrate how this would work, right now we could disable exit_on_close like this:

fn main() {
    App::build()
        .add_plugins_with(DefaultPlugins |group| {
            group.disable::<bevy::window::WindowPlugin>()
        })
        .add_plugin(bevy::window::WindowPlugin {
            add_primary_window: true,
            exit_on_close: false
        })
        .run();
}

Now lets imagine a crate that needs such change to work. Such crate would either have to create (and maintain) their own full version of the DefaultPlugins, or force the user to always include the above boilerplate.

With this PR the crate would provide this:

pub struct DefaultFooPlugins;

impl PluginGroup for DefaultFooPlugins {
    fn build(&mut self, group: &mut PluginGroupBuilder) {
        let mut default_plugins = DefaultPlugins {};
        default_plugins.build(group);
        group.reconfigure(bevy::window::WindowPlugin {
            add_primary_window: true,
            exit_on_close: false
        });
        group.add(FooPlugin);
    }
}

and the user would just have to do this:

fn main() {
    App::build()
        // .add_plugins(DefaultPlugins)
        .add_plugins(DefaultFooPlugins)
        .run();
}

The

[cart]

This is a good idea, but before merging I think we need to decide what #1255 looks like (and in general how we want to handle plugin configuration).

I've currently been pushing for a move to "resources as config" over setting config in the plugin type itself because "dynamic plugin loading" implies that the actual type of the plugin (and its constructor) is erased at load time. It also opens the door to a more "dynamic" form of configuration that can be modified at runtime from within the ecs.

This pr might be the way to go, but before making this style of configuration easier, I want to make sure this is the direction we want to go with.

[alice-i-cecile]

I've currently been pushing for a move to "resources as config" over setting config in the plugin type itself because "dynamic plugin loading" implies that the actual type of the plugin (and its constructor) is erased at load time. It also opens the door to a more "dynamic" form of configuration that can be modified at runtime from within the ecs.

I like this idea quite a lot: it's natural, and tackles some of the bigger questions about how to integrate a heterogenous ecosystem in a single program.

For posterity: this also ties into some of the much broader thinking around config / metadata in general as seen in #1375.

[rmsc]

I agree, lets wait. Plus this did feel a bit like abusing the existing API.

[cart]

I'm going to close this for now in favor of "resources as config". I'm happy to revisit later if/when that ceases to be the pattern we're encouraging. Also feel free to continue the discussion here if there are dissenting opinions.