Do the following:

- `b`, `Tab`

The Vomnibar crashes.  The problem is that we're advancing the selection
even though there are no suggestions available.

Here, we require there to be a suggestion or suggestions before
advancing the selection.

The code to handle the focus for UI components has been tweaked and
adapted over time, and has become quite complicated (and brittle).  This
reworks it from scratch, and co-locates similar code which does related
things.

Fixes #2099.

The help-dialog UI component was ignoring requests to "hide" when other
frames are focused (because previously it covered the whole screen, and
no other frame could get the focus).

With f0911e52f0e71c6d2539bdc74a09ff2dbd5ab125, the help dialog no longer
covers the whole screen, so it must listen for and react to
"frameFocused" events.

However, the help dialog should not "hide" when the frame that is
focused is itself!  This required a little extra plumbing.  That
plumbing is helpful, though, because it allows individual UI components
to decide what to do when another frame receives the focus (as opposed
to the previious version, which simply unilaterally sent a "hide"
message).

With this, if we're in custom search mode and the cursor is at the start
of the vomnibar input and the user types <Delete>, then we exit custom
search mode and reinstate the keyword (and arrange for the cursor to be
in the right place).

This makes it possible to change (or just disable) the custom search
engine without having to first wholly delete the query.

This avoids a flicker whereby the keyword is first inserted into the
input, then removed.

Conflicts:
	background_scripts/completion.coffee

In omni mode, the vomnibar suggestions are updated asynchronously.
Therefore, the contents of the primary custom search-engine suggestion
may be behind the actual contents of the comnibar input.  So, we
reconstruct the custom search-engine query on "enter".

(This fixes a long-standing race condition.)