Inspect and edit deferred commands just before they are applied?

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

It would be useful to have a way to inspect and edit deferred ECS commands before they are applied.

This may be a more efficient and generic solution to problems like retrieving data from resources and entities just before they are deleted, or for other applications.

## What solution would you like?

I'm thinking of having some kind of a `InspectDeferred` schedule that is run by `apply_deferred` system just before applying any deferred commands, and an API to actually manipulate or at least read the deferred commands list from such systems.

A developer could then insert exclusive `&mut World` systems into that schedule, which, for example, read the remove commands that are about to be executed, and then read and preserve just the data it needs.

Or maybe even edit the list of commands, and add/edit/remove commands that may be undesired for some reason. That may make it easier to manipulate commands done by another plugin, perhaps from a crate developed by someone else, if it exhibits undesirable behavior in this sense.

(In my particular case, for something I'm slowly working on, it would be very handy to be able to have hold of the exact entity IDs of entities that get deleted, which sounds like it would necessitate having the ability to edit the deferred commands list to preoccupy an ID of an entity with `World::get_or_spawn` after it gets deleted but before any new ones are spawned, or outright replace the command with a personal solution.)

The proposed solution raises a question about inserting systems into that schedule that themselves send deferred commands. May be worth to make systems that have a `Commands` parameter panic when run in this context to prevent the possibility?

## What alternative(s) have you considered?

Wait for some solution to just the problem of retrieving deleted components and resources. Personally fork and edit code of crates with undesired behavior, and hope users of your code don't perform such behavior too. Create a personal solution of a command that preserves component/resource data before deleting it and urge everyone involved to use that instead of the stock Bevy remove commands.

## Additional context

Haven't looked much. I apologize if this was already considered.

No source file or test is named. Start by tracing the apply_deferred system and the deferred command list, then evaluate the proposed InspectDeferred schedule and API for reading or editing commands, including the unresolved behavior of systems that send Commands in that context. Done would require a settled design for inspecting, modifying, and safely applying deferred commands.

Written by the indexing model from the issue text.