Add ability to operate search forms that lack clickable "submit" controls.

[duhrer]

We can now enter text in search inputs using the onscreen keyboard. Up to this point, that has been sufficient, as you:

1. Click on the search input to open the onscreen keyboard.
2. Enter some text.
3. Click "Enter" to update the search form with your text.
4. Navigate to whatever control submits the search.
5. Click that control to perform the search.

I suspected we would eventually need to simplify this at some point, for example, by entering the text and performing the search in one step, eliminating steps four and five.

Now, in testing sites like Science Direct, I have concrete examples of search inputs that don't have a keyboard navigable control to perform the search (I suspect they expect you to hit Enter on the keyboard).

We also need to see why the "X" that can be used to clear the search field is tab-navigable but not reachable using the comparable actions in the gamepad navigator.

[duhrer]

I updated the model listener that waits for input value changes in the input mapper to handle this. If the "last external focused" element is a search field, we look for the enclosing form and submit that.

I was a bit concerned that the change in behaviour for some but not all fields would make the "Update Field" wording in the onscreen keyboard modal misleading. I addressed this by making the onscreen keyboard aware of the "last external focused" element.

When that changes, it chooses whether to label the update button using "Update Field" or "Search". Although I'd rather not rework the keyboard itself (changing it to a number pad, for example), it might be possible to use a similar strategy to handle #143 (choosing whether to display a <textarea/> or <input type="type"/>).

[duhrer]

This works for more search forms, but doesn't seem to work for the search on Vimeo, which we may need to write up separately, as they seem to heavily assume that you can hit "enter" to activate many of their controls.