Add configuration to automatically disable/enable features when running in the web

[TimJentzsch]

We should provide an option to automatically disable default features and enable features when running the app on the web.

For example, via a package.metadata.bevy_cli.web.default-features = false configuration in Cargo.toml.

Use case: Some features, like file watching, are only available on native platforms.
It's convenient to have them enabled by default, so that cargo run gives you hot asset reloading.

But then we have to always add --no-default-features when running bevy run web, which is a regression in TheBevyFlock/bevy_new_2d#312.
It would be nice if we could permanently configure it instead so the user doesn't have to type it out every time.

CLI options should take precedence over the Cargo.toml configuration.

[TimJentzsch]

We can take the bevy_lint implementation as reference.

One challenge will be that there are four useful configurations:

1. Native dev
2. Native release
3. Web dev
4. Web release

and possible the overarching ones (for all, for native, for web).
Managing them in the code could become messy, especially to apply the defaults to the CLI provided values afterwards...

The clap value_source function could help, because it allows us to determine if the default was used in CLI and then overwrite it with the appropriate config value.
But doing so for all the relevant values could create a lot of boilerplate code.

[TimJentzsch]

Another idea: We introduce "magic" feature flags, similar to the "magic" default feature.
The cargo metadata output includes which features are defined for the package.

So if the user runs bevy run --release web we could check if a default_web_release feature is defined and enable it automatically.

Advantages

• Simple: You just add feature flags for what you need, you don't need Bevy CLI specific configuration.
• Independent: If you don't have Bevy CLI installed or want to migrate to a custom solution, you can still just enable the feature flags manually. It would be consistent across every app, instead of having to check the specific configuration.
• Easy: We don't need to implement the Cargo.toml logic and potential merging (yet).
• Less verbose, you can define everything in the [features] section.

Disadvantages

• Magic: The solution where every feature is defined explicitly for the different cases is probably less surprising or confusing for users. They might have to consult the docs to understand what's going on / if the app isn't working as expected.
• We don't setup the Cargo.toml stuff yet, but probably need it for other stuff in the future.
• You can't define --no-default-features for one specific configuration. So in some scenarios you would have to leave default empty and then define the defaults e.g. in default_native.