App::take_blur_request, and a press on a focused select_on_focus field positions the cursor

Two gaps found while using trust's address box on a phone, both about what happens to a text field once it holds the focus.
Dropping the focus. An app could ask for the focus of a widget, through `App::take_focus_request`, but had no way to give it up. A browser needs to: once an address is submitted the field has done its job, yet it kept the focus, so the on-screen keyboard stayed over the page that had just been asked for, and came back whenever the window was raised, since ltk enables the input method again on the text-input `enter` that follows while a text field holds the focus. `App::take_blur_request` is the counterpart: return `true` once and the run loop calls `set_focus( keyboard_focus, None )`, the same call the back request already uses to blur a text field, so the text-input disable and `on_text_input_focused( false )` come with it. It is handled just before the focus request, so an app that asks for both in one cycle ends up focused, which is what "open a new tab and type" needs; a pending `focus_retry` from an earlier cycle is cleared, or it would hand the focus straight back to the widget it was taken from.
Positioning the cursor in a `select_on_focus` field. `handle_text_pointer_down` and `handle_text_pointer_drag` returned at once for a field built with `.select_on_focus( true )`, so that the press that focuses it keeps the whole-value selection `set_focus` has just installed. The guard did not distinguish that press from a later one: in a field that already had the focus, no press ever placed the cursor and no drag ever selected a range, with a finger or with a mouse. That suits a numeric picker poorly and an address box not at all, where correcting one character of a long URL meant retyping it. `AppData` gains `press_on_focused`, computed in both press paths, touch and pointer, right before their `set_focus`: whether the press landed on the widget that already held the focus. The two guards now apply only when it did not. The first press on such a field selects everything, as before; a press on it while focused collapses the selection to the byte offset under it, and a drag from there extends the selection.
Not changed. `handle_text_select_word` keeps its `select_on_focus` guard, so a double press on such a field still leaves the whole value selected rather than a word. The right-button path, which opens the context menu without touching the selection, never reached these functions and is unaffected. `set_focus` still moves the cursor to the end and reselects when it is called for the widget that already has the focus; a programmatic focus request on a focused `select_on_focus` field therefore selects everything again, which is what an address-box shortcut wants.

src/event_loop/text_editing/selection.rs

@@ -127,7 +127,7 @@ impl<A: App> AppData<A>
 			find_handlers( &self.surface( focus ).frame.widget_rects, idx ),
 			Some( WidgetHandlers::TextEdit { select_on_focus: true, .. } ),
 		);
-		if select_on_focus { return; }
+		if select_on_focus && !self.press_on_focused { return; }
 		let ( rect, value, multiline, secure, align, font_size ) = match self.text_input_geometry( focus, idx )
 		{
 			Some( v ) => v,
@@ -161,7 +161,7 @@ impl<A: App> AppData<A>
 			find_handlers( &self.surface( focus ).frame.widget_rects, idx ),
 			Some( WidgetHandlers::TextEdit { select_on_focus: true, .. } ),
 		);
-		if select_on_focus { return; }
+		if select_on_focus && !self.press_on_focused { return; }
 		let ( rect, value, multiline, secure, align, font_size ) = match self.text_input_geometry( focus, idx )
 		{
 			Some( v ) => v,