See #2147.

Chromium's implementation of event.key currently fails to take account
of keyboard mappings (e.g. neo2).

Here, we favour using event.keyIdentifier (while it's available) as a
workaround.

Adds single left/right angle quotation marks to next/previous patterns

This was an oversight from a5262f4e68f62a922c9c05d871c4a874f6737a7b.

event.keyIdentifier is depricated and will be removed soon.  It is being
replaced by event.key.  Unfortunatelty, event.key is not yet available
in the stable Chrome version.

Here, we use whichever API is available.  In due course, we can remove
the event.keyIdentifier implementation (and a considerable amount of
machinery surrounding it).

For the time being, if both APIs are available, then we verify one
against the other and show a warning message of they do not match.  This
should help us track down any issues which arise.

Using event.key has the additional benefit of correctly detecting
shifted characters on the numbers row on keydown, which has been a
problem for some users.

Fixes #2128.

Note:  We have a problem with the tests.  phantomjs does not currently
support event.key, and possibly never will.

This reverts commit ee8c235aeaf52d2bc867a00c37731690e337c7ff.
This reverts #2117.

This breaks next/prev on Reddit (it chooses a different link).

Reddit is an important site, so we should unwind this for now.

Mention @sco-tt.

Fix UI-component initialization issues (maybe).

This fixes some UI component initialization issues.  It's a long
story...

The problem.

- Go to this page: http://www.thejournal.ie/seanad-election-results-2016-2737768-Apr2016/
- Click one of the links from the "Most Popular" box on the right.
- Navigate back (`H`) and, as the original page is loading, activate the Vomnibar.

In 1.54 this renders Vimium unusable.  In `master` this renders the
Vomnibar unsable, but the rest of Vimium usable.

It seems the source of the issue is that we're initializing UI
components too soon.  We need to wait until the `readyState` is
"complete".

With this PR:

- The Vomnibar is initialised when the `readyState` is "complete" (in
  the top frame only, and only if Vimium is enabled).  Requests arriving
  prior to then are silently discarded.
- The HUD is also initialized only when the `readyState` is "complete";
  however, requests arriving before then are queued.  So, if the user
  immediately enters insert mode, then the "Insert mode" indicator will
  eventually be displayed.
- The help dialog silently discards requests until the `readyState` is
  "complete.

I'm posting this as a PR because:

1. It needs some visibility.
2. With this, if the `readyState` *never* reaches "complete", then the
   Vomnibar would be unusable.  And that's pretty serious.

There are circumstances when we hav two (identical) vimiumFlash elements
displayed: specifically, when using the waitForEnter keyboard blocker.

So, we should use a class (rather than an id) to style the flash
element.