`TextEdit` does not "consume" keypresses it reacts to, leading to both the widget and app reacting to the same keypress

**Describe the bug**
`TextEdit` (and maybe other widgets) reacts to `Esc` to defocus. If the application checks `ctx.input()` and `!wants_keyboard_input()` to use `Escape` as a shortcut for, e.g. a Cancel button, then when a `TextEdit` is focused and the user hits `Esc` to defocus it (hoping to revert their edits), then the `TextEdit` correctly defocuses, and clears the `wants_keyboard_input()` flag, which leads the app to incorrectly react to the `Esc`, so Esc double-acts by (a) cancelling focus and (b) doing whatever Cancel does.

**To Reproduce**
Steps to reproduce the behavior:
1. Create an app with a `TextEdit` that does something `ctx.input()` for `Escape` to be released when `!wants_keyboard_input()`.
2. Edit the text in the `TextEdit`
3. Press `Esc`
4. Observe the `TextEdit` defocuses, and that `wants_keyboard_input()` goes false leading the app to also detect an `Escape` release

**Expected behavior**
The `TextEdit` and other widgets (for example, modals) should "consume" the events they process so that code later in the frame does not also react to those events.

egui: `0.30`

Start with TextEdit's Escape handling and the ctx.input()/wants_keyboard_input() flow described in the issue, then compare how other widgets such as modals process key events. The change is complete when an Escape handled by a focused TextEdit or another widget does not also trigger the application's shortcut logic in the same frame.

Written by the indexing model from the issue text.