Track the global focus state of the UI

[mwcampbell]

Closes #1845.

[emilk]

Very nice, I like it! But please add some docstrings to the two fn has_focus to explain which one heeds RawInput::has_focus, and why

[mwcampbell]

Another option would be to make the Focus::id field pub(crate) (I have to do that anyway on my AccessKit branch), then replace Memory::has_focus with a new Context::has_focus function that checks both the memory and raw input. Then Response::has_focus can simply call Context::has_focus. Of course, I'd have to fix the widgets that directly call Memory::has_focus, but it would be more consistent that way.

[emilk]

@mwcampbell I like that approach!

[mwcampbell]

@emilk On closer investigation, I don't think my suggested solution will work. The most obvious reason is that other functions in Memory call Memory::has_focus. So I would at least have to keep that function and make it internal or pub(crate). But also, in some cases where Memory::has_focus is used, we don't want the outcome to depend on whether the window has focus. For example, if you put a DragValue into keyboard editing mode, then move focus away from the window, then come back, you probably don't want the DragValue to switch to a button in the meantime. So I think I just have to document the difference between Response::has_focus and Memory::has_focus, or even add a second function in Response that takes global focus into account. Sometimes widgets really should check the global focus, e.g. when determining whether to render a border around a text edit.

[emilk]

Let's just go with added docstrings for now!