Consider renaming or rearchitecting `AssetEvent`

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

After the event rearchitecture, we have two distinct names for two distinct but related concepts:
- Messages are buffered
- Events are immediately handled

As mentioned in that PR, we should not use a suffix to indicate whether something is an event or a message. Rather, the types should reflect what information is being transmitted (`Collision` is better than `CollisionMessage`).

But there's a bit of a conflict here for some types that happen to have `Event` in its name, as it is notifying the API caller about some kind of "event", where "event" does not mean Bevy's notion of event, but "something changed or happened"

In my personal migrations, I have a ton of code now that reads `MessageReader`. This is confusing. And if I'm confused by this, I think a newcomer will be even more confused.

## What solution would you like?

Rename at least `AssetEvent` as it's somewhat common. Maybe also others like `RawWinitEvent` if we have a nice solution, but that's secondary. @viridia suggested `Status` as a suffix, which I think conveys the meaning well when read in `MessageReader`: here's a `Message` about the new status of the asset.

## What alternative(s) have you considered?

- Leave it
- Document extremely clearly how our naming works everywhere a beginner might read it
- Use a different suffix
- Per discussion below: `AssetChange`, `AssetLifecycle`

## Additional Information

Relevant PR: https://github.com/bevyengine/bevy/pull/20953
See @janis-bhm's comments there