Revert "Clean up image resources for the current window (#45969)"

[SomeoneToIgnore]

This reverts commit 94faaeb.

The logic changed in the original PR is either misplaced or lacks a counterpart that reacts on gpui::Image drop one way or another.

The change was dropping the texture out of the global rendering atlas when an image preview tab was disposed of, while in reality, another instance (agent panel or another image preview tab) could require the very same atlas entry to be rendered meanwhile.

Currently, only RetainAllImageCache in Zed does any kind of image cleanup, and any other image usages will leak memory.
What makes it harder is that the atlas entry needs to live as long as a particular Arc<Image> lives, and some public gpui API expects this type to stay:

zed/crates/gpui/src/platform.rs

Lines 1851 to 1866 in e747cfc

	pub fn use_render_image(
	self: Arc<Self>,
	window: &mut Window,
	cx: &mut App,
	) -> Option<Arc<RenderImage>> {
	ImageSource::Image(self)
	.use_data(None, window, cx)
	.and_then(|result| result.ok())
	}
	/// Use the GPUI `get_asset` API to make this image renderable
	pub fn get_render_image(
	self: Arc<Self>,
	window: &mut Window,
	cx: &mut App,
	) -> Option<Arc<RenderImage>> {

For image viewer in particular, we need to consider why RetainAllImageCache is not used there; for the global, normal fix, we need to consider ways to have cx and window and a way to react on Image drop.
As an option, we could break the gpui API (as it happens periodically already) and use Entity<Image> instead of Arc, then react with cx.on_release_in for each such image.

Closes #46755
Closes #46435

Release Notes:

• Fixed panics on concurrent image handling

[SomeoneToIgnore]

/cherry-pick preview
/cherry-pick stable

[zed-industries-bot]

	Messages
📖	This PR includes links to the following GitHub Issues: #46183 If this PR aims to close an issue, please include a Closes #ISSUE line at the top of the PR body.

Generated by 🚫 dangerJS against e0479f1