New features deserve migration guides

## Problem

Adding new features sometimes gates previously accessible types or functionality, this is a breaking change that should be documented in migration guides.

This is especially problematic when the new feature is a part of default features, meaning that it's much less likely to get caught as a breaking change (because it does not break projects who enable default features, only projects who specify their features manually).

### Example

When migrating to 0.15.0, my project failed to compile because of a missing `Window` type, which requires the new `bevy_window` feature.

## Solution

PRs that introduce new features should be mentioned in the migration guides, possibly even getting sections.
(Though it might be enough to have a single section that documents that new features have been added and that it might be necessary to evaluate them for your project.)

Start by reviewing the existing migration guides and PRs that introduce new features. Determine how manually specified features can gate previously available types or functionality, then document those breaking changes or establish the proposed general migration-guide section. Done means affected feature additions are consistently identified and explained to users.

Written by the indexing model from the issue text.