`Entry`-style APIs for `Query`

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

It is common to need to write code which operates on a component, or adds it if it exists.

Because of this, we have a wonderful (and under-appreciated) method: [`EntityWorldMut::entry`]. This mirrors the standard Rust convention: similarly methods exist on `HashMap` for example.

## What solution would you like?

### `Entry` `QueryData` type

This type would return an `Entry`-style wrapper over a `Mut`. This could be converted to a `Mut` (or a eldritch equivalent) using methods like `.or_default()`, allowing you to operate on the data as if it was always there.

In order for this to work smoothly, we need to somehow actually send the command to spawn / insert the data you just mutated after the system concludes. I *think* a `Drop` impl might be able to do the trick, although a persistent mutable reference to the command data inside of `EntityCommands` stored inside of the contained `Query` might work too, albeit with some level of pain due to the borrow checker.

## What alternative(s) have you considered?

Leave it alone: you *can* just write branching code and take both `Query` and `Commands`.

## Additional context

This was originally proposed by @ecoskey [on Discord](https://discord.com/channels/691052431525675048/749332104487108618/1473912792682598524).

Start by reading EntityWorldMut::entry and the existing QueryData, Mut, Commands, and EntityCommands APIs to understand their ownership and command behavior. The issue is done when an agreed Entry-style QueryData design supports the proposed mutation-or-insert workflow and its command scheduling behavior is specified and implemented.

Written by the indexing model from the issue text.