Potentially reconsider how bevy_egui interacts with picking by default

[mweatherley]

I work on a Bevy application that has camera viewports composited into window where the rest of the UI is made with egui. In 0.32, the change to EguiContextSettings makes it so that picking events anywhere in the main window are blocked by bevy_egui. Of course, visually speaking, these camera viewports lie "on top of" the UI.

(Actually, the behavior is weirder than that, since pointer events seemingly leak through as long as the mouse button is held down, but this is obviously not what you'd want.)

Disabling this requires creating a system or whatever to alter the relevant value in EguiContextSettings for the main window. In other words, I created a plugin just to undo the work in #338.

The main issue from my point of view is not the fact that bevy_egui causes pointer events to get captured per se, but more a matter of defaults and expectations. I can imagine that in plenty of scenarios (e.g. egui windows floating over a camera viewport), this behavior makes a lot of sense. In reality, what happened was that I bumped the bevy_egui version as I was migrating to Bevy 0.15, and it took a long time for me to realize that bevy_egui even interacted with picking at all, since my baseline expectation is generally for plugins not to interact with the picking backend by default but to do this through other means (e.g. a separate plugin).

Perhaps this is also a shadow of some way in which the camera views could be better integrated; ideally, of course, we would probably not be seeing that egui wants the mouse input in the egui::Context in the first place.