bevy_ecs should have more modular feature flags

## What problem does this solve or what need does it fill?

> Simple: Easy for newbies to pick up, but infinitely flexible for power users.
> Modular: Use only what you need. Replace what you don't like.

> Modularity over deep integration: Individual crates and features should be "pluggable" whenever possible. Don't tie crates, features, or types together that don't need to be.

Within the documentation for Bevy's ECS we have a section describing its features, the list is as follows:
- Query Filters
- Change Detection
- Component Storage
- Component Bundles
- Events
- Observers

None of these features are optional, but they are implied to be additional by the fact that they are called features. In brief, I argue that it is an issue that these features are not optional.

To provide further argument, I will detail my own user experience.

I like the simplicity of ECS, but as the ECS feature set extends, I find that it detracts from that. As someone unfamiliar with the abstractions that are observers, I don't dismiss them but I would expect myself to only appreciate them after replicating and discovering the pattern, that they automate, myself.

Simplicity and modularity, I find that it would be in the name of these design principles to allow some of these features to be optional.

Theoretically, you can have scenarios where it benefits compile times and performance too.

## What solution would you like?

I would use the cfg attribute and create feature flags for bevy_ecs, for each listed feature, and each distinct storage type. Every feature would be enabled by default.

## What alternative(s) have you considered?

- You could create the features as seperate crates that're not a part of bevy_ecs.

- I can't imagine that plugins would work for this.