Awkward API for TexturesDelta in integrations

[derivator]

The API for integrations around TexturesDelta introduced in #1110 seems a bit awkward to me:
egui_winit::State::handle_output takes ownership of egui::Output and returns egui::TexturesDelta, suggesting that egui_winit is somehow involved or needed to get the TexturesDelta, when that's not actually the case.
Perhaps TexturesDelta could be moved out of Output and into a new struct containing exactly everything needed to render the gui (i.e. the Vec<ClippedShape> that egui returns at the moment).
As an alternative, egui_winit could just not take ownership of Output and return nothing.

[emilk]

I agree it is not great. It is also a bit weird that egui::Output doesn't contain all the output of egui (omitting the shapes to be painted).

Perhaps egui::Output should be renamed BackendOutput or something, and then we introduce

pub struct Output {
    pub backend: BackendOutput,
    pub textures_delta: epaint::textures::TexturesDelta,
    pub shapes: Vec<ClippedShaped>,
}

though it is not exactly clear to me what would go in BackendOutput. For instance, where should needs_repaint go?

[derivator]

BackendOutput sounds ambiguous to me. Isn't rendering also part of the backend? It could also be misunderstood to be output from the backend. I can't really think of a better name right now though, but here's some words that might do the trick in the right combination: OS, platform, integration, window manager.

Maybe something like this?:

pub struct Output {
    pub for_platform: PlatformOutput, // current `Output`
    pub for_rendering: RenderingOutput, // shapes, texture delta
    pub needs_repaint: bool, // ambiguous items that could go into either category go in top level struct
}

[emilk]

Take a look: #1292