Automatically detect and warn about duplicate Bevy (or Bevy-depending) crates

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

When working with third party dependencies, it's very common to get inscrutable errors about how the trait `Plugin` (or `Component` or `Resource`) isn't implemented.

This gets particularly nasty when you're depending on two different versions of a Bevy plugin that use their own component or resource types to communicate (raised by @aevyrie). If they're semver-incompatible, but rely on the same version of Bevy, everything will compile correctly, but nothing will *work*.

The two types will be different, but with the same name: you'll get duplicate components and all interop will silently break.

## What solution would you like?

Borrowing from `cargo-deny`, we should inspect the `Cargo.lock` (or perhaps `Cargo.toml`) of the user's crate, and warn if problems are detected.

We want to warn if:

1. Multiple versions of `bevy` are in tree.
2. Multiple versions of the same crate which depends on `bevy`, `bevy_app` or `bevy_ecs` are in tree.

This should be done during `App` initialization, before we run it for the first time, and panic if a problem is detected.
This needs to be done as part of the `App` lifecycle to ensure it's always caught, and should panic, as this is a critical error that should never be ignored.

## What alternative(s) have you considered?

The first problem can be interactively detected with

`cargo tree -i bevy`

Similarly, you can scan for duplicates in the same way.

At a CI level, one can use `cargo-deny`, manually adding all of your Bevy plugin crates to the "deny duplicate dependencies list". However, this will only catch the problem once you hit CI: making a PR or checking in mysteriously broken code is an unlikely pattern.

Ultimately though, neither of these solutions solve it for the users who need it most: users who don't *know* they have a problem, either due to subtle effects or being new to Bevy and Rust.

We could instead have some editor-based process to check for this, but a) that doesn't currently exist and b) not all users of Bevy will use the editor, and this check is just as important to them.

Start by reviewing how dependency metadata from Cargo.lock or Cargo.toml could be inspected and where App initialization occurs in the lifecycle. Compare the requested checks with cargo tree -i bevy and cargo-deny. Done means duplicate Bevy versions or Bevy-dependent crates are detected and cause a warning or panic before the app runs.

Written by the indexing model from the issue text.