Bug fix: arrow keys won't move focus away from TextEdit

[emilk]

• Caused by Change focused widget with arrow keys #3272
• Closes Merge of "change focused widgets with arrow keys" broke l/r keys use while editing single line text fields #3324

This PR introduces Event::set_focus_lock_filter which lets you tell egui what events a widget has exclusive access to:

/// Controls which events that a focused widget will have exclusive access to.
///
/// Currently this only controls a few special keyboard events,
/// but in the future this `struct` should be extended into a full callback thing.
///
/// Any events not covered by the filter are given to the widget, but are not exclusive.
#[derive(Clone, Copy, Debug)]
pub struct EventFilter {
    /// If `true`, pressing tab will act on the widget,
    /// and NOT move focus away from the focused widget.
    /// 
    /// Default: `false`
    pub tab: bool,

    /// If `true`, pressing arrows will act on the widget,
    /// and NOT move focus away from the focused widget.
    /// 
    /// Default: `false`
    pub arrows: bool,

    /// If `true`, pressing escape will act on the widget,
    /// and NOT surrender focus from the focused widget.
    /// 
    /// Default: `false`
    pub escape: bool,
}

Future work

The event filter was the simplest possible for what is needed today. In the future we should replace it with some sort of callback.

Alternatives

Another way to solve this would be that widgets mark events as handled/consumed. The widget-focus-move logic runs at the end of the frame, so it would just ignored consumed events.

One downside with that would be requiring attaching some bool to each event, which would require quite a bit of a refactor.

Another problem is that it won't handle the case when several widgets are interested in events, since there is no guarantee which orders widgets will be executed (it is immediate mode!). The only thing that could work in that case is an event filter.