use general Renderer type in integration example

[Davidster]

This allows applications that are based off the integration example to use the generic iced_renderer::Renderer type in the rest of their codebase and to work with third party libraries.

I couldn't compile the example with the plotters-iced lib without this change. See #2061 for more details.

[hecrj]

iced_renderer::Renderer is less generic than iced_wgpu::Renderer.

The fact that you can easily change the types like this shows that there is no inherent limitation to iced when it comes to handling different renderers.

[Davidster]

Yeah, I was wrong in the original issue, there is no limitation in iced.

But I believe the PR is still valid: writing the integration example with the backend-agnostic renderer type makes it easier to use with other iced code. Sorry I didn't discuss this with the team first, I figured it was a no-brainer.

[hecrj]

iced_renderer::Renderer isn't backend-agnostic, however!

It is a Renderer enum that supports runtime switching between iced_tiny_skia and iced_wgpu. It is completely unnecessary if you only plan on using iced_wgpu.

Instead, library code like plotters-iced should rely only on the Renderer traits in iced_core and iced_graphics to allow users to use any renderer implementation, like the Program trait does.

[Davidster]

Thanks for the example with the Program trait. It's starting to make more sense now