Refactor window creation logic (#22088)

# Objective

Fixes #21948

Currently we tell winit to spawn any new `Window`s during the
`about_to_wait` lifecycle method, but that's unreliable: if no new
events appear while we're already waiting it could take an arbitrarily
long time, or no new events could appear at all so we never spawn the
window. This is especially bad when going from 0 to 1 `Window`s, as many
events are related to the existing window.

## Solution

Check for new windows in `resumed` for the initial window (which is also
what winit examples do) and in `user_event` for new windows.

I also did some other improvements while I was investigating this:
* Inlined the `Added<Window>` query filter into `CreateWindowParams`, as
the logic didn't make sense with any other filter.
* Insert the `EventLoopProxyWrapper` resource when the plugin builds
instead of inside the `winit_runner`. This currently makes no practical
difference, but in another version of this PR I had a crash because the
observer tried to use the resource before the runner started. It's also
a more natural way to do it.
* Made `WinitPlugin` no longer generic, and removed the
`custom_user_event` example. The functionality it provides (being able
to send events into bevy from the outside) only works in one direction,
and I don't see why it needs to go via winit instead of a dedicated
plugin with channels. ~~If this feature is useful for reasons I've
missed then I'm happy to re-add it.~~ edit: winit is removing custom
user events in 0.31, which made me even more confident it's the right
direction for us too.

## Testing

Run different examples and see that the window spawns in a timely
fashion, edit the `multiple_windows` example as in #21948 and see that
the window spawns.