New widget interaction logic

[emilk]

• Closes Do all widget interaction at the start of the frame #3936
• Closes Windows cannot be resized when in front of a plot #3923
• Closes Fix disabled sliders being interactive. #4058

The interaction code is now done at the start of the frame, using stored WidgetRects from the previous frame.

The intention is that the new interaction code should be more accurate, making it easier to hit widgets, and better respecting the rules of overlapping widgets.

There is a new style::Interaction::interact_radius controlling how far away from a widget the cursor can be and still hit it. This helps big fat fingers hit small widgets on touch screens.

This PR adds a new Context::read_response which lets you read the Response of a Widget before you create the widget. This can be used for styling, or for reading the result of an interaction early (to prevent frame-delay) for a widget you add late (so it is on top of other widgets).

⚠️ BREAKING CHANGES

Memory::dragged_id, Memory::set_dragged_id etc have been moved to Context.
The semantics for Context::dragged_id is slightly different: a widget is not considered dragged until egui it is sure this is not a click-in-progress. For a widget that is only sensitive to drags, that is right away, but for widgets sensitive to both clicks and drags it is not until the mouse has moved a certain distance.

TODO

• Fix panel resizing
• Fix scroll hover weirdness
• Fix Resize widget
• Fix drag-and-drop
• Test all of egui_demo_app
• Change is_dragging API
• Consistent naming of start/stop or begin/end drag
• Test egui_tiles
• Test Rerun
• Document
• Document breaking changes in PR description
• Test one final time

Saving for a later PR

• Fix Unable to ineract with table row widgets (regression) #4047
• Specify what the response order for e.g. ui.horizontal is

I think both these can be fixed if each Ui registers themselves as a WidgetRect, with the possibility to interact with it later, as if the interaction was under all widgets on top of it.