Solves bevyengine#5069.

`AssetChanged<T>` is just a thin wrapper around the `&Handle<T>` query,
with additional logic to check in `Assets<T>` if the corresponding
`HandleId` was changed between the last and current runs of the system.

This adds some overhead in the `asset_event_system` for keeping track of
when which handle got updated. Otherwise, the overhead is constrained to
the `AssetChanged` query, which is ripe for optimizations.

NOTE: We chose to update the `change_ticks` hash map during asset event
propagation rather than when accessing the asset, because we need access
somehow to the current `change_tick`. Updating the tick hash map during
modification would require passing the `change_tick` to all methods of
`Assets` that accepts a `&mut self`. Which would be a huge ergonomic
loss.

As a result, the asset change expressed by `AssetChanged` is only
effective after `asset_event_system` ran. This is in line with how
`AssetEvents` currently works, but might cause a 1 frame lag for asset
change detection.

A potential future update could implement some sort of specialization so
that when `Assets` is accessed through a `ResMut`, the called methods
are called with the `ResMut`'s change_tick. But with current rust, this
is either impossible or causing huge ergonomic loss on the `Assets` API.

Solves bevyengine#5069.

`AssetChanged<T>` is just a thin wrapper around the `&Handle<T>` query,
with additional logic to check in `Assets<T>` if the corresponding
`HandleId` was changed between the last and current runs of the system.

This adds some overhead in the `asset_event_system` for keeping track of
when which handle got updated. Otherwise, the overhead is constrained to
the `AssetChanged` query, which is ripe for optimizations.

NOTE: We chose to update the `change_ticks` hash map during asset event
propagation rather than when accessing the asset, because we need access
somehow to the current `change_tick`. Updating the tick hash map during
modification would require passing the `change_tick` to all methods of
`Assets` that accepts a `&mut self`. Which would be a huge ergonomic
loss.

As a result, the asset change expressed by `AssetChanged` is only
effective after `asset_event_system` ran. This is in line with how
`AssetEvents` currently works, but might cause a 1 frame lag for asset
change detection.

A potential future update could implement some sort of specialization so
that when `Assets` is accessed through a `ResMut`, the called methods
are called with the `ResMut`'s change_tick. But with current rust, this
is either impossible or causing huge ergonomic loss on the `Assets` API.

Solves bevyengine#5069.

`AssetChanged<T>` is just a thin wrapper around the `&Handle<T>` query,
with additional logic to check in `Assets<T>` if the corresponding
`HandleId` was changed between the last and current runs of the system.

This adds some overhead in the `asset_event_system` for keeping track of
when which handle got updated. Otherwise, the overhead is constrained to
the `AssetChanged` query, which is ripe for optimizations.

NOTE: We chose to update the `change_ticks` hash map during asset event
propagation rather than when accessing the asset, because we need access
somehow to the current `change_tick`. Updating the tick hash map during
modification would require passing the `change_tick` to all methods of
`Assets` that accepts a `&mut self`. Which would be a huge ergonomic
loss.

As a result, the asset change expressed by `AssetChanged` is only
effective after `asset_event_system` ran. This is in line with how
`AssetEvents` currently works, but might cause a 1 frame lag for asset
change detection.

A potential future update could implement some sort of specialization so
that when `Assets` is accessed through a `ResMut`, the called methods
are called with the `ResMut`'s change_tick. But with current rust, this
is either impossible or causing huge ergonomic loss on the `Assets` API.