We were leaking both the `keypress` and the `keyup` events when marks
are created and used.

This is a follow up to the move to using keydown for all events, and
fixes a bug I introduced.

Specifically, we were reacting to the first keydown event, which could
be just the `Shift` key.

There were two problems, both stemming from the fact that the
notification was being displayed in the top frame, even if the mark was
triggered in another frame:

1. That looks odd, because we close the HUD in one frame then open it in
   another.

2. As a side effect, we were moving the focus to the top frame.

Here, we work out what's going to happen before sending the message to
the background page.  This allows us to display the message in the HUD
in the frame which generated it.

On some keyboards (who knows?) "`" or "'" could be shift keys.  In this
case, with the previous implementation, these would be treated as global
marks and `` would be unusable.  This commit fixes that problem.

With global marks, we may later create a new tab when the mark is used.
When doing so, we should always be using the URL and scroll position of
the top frame within the tab.  For example, if a global mark is created
from within the Hangouts frame of Google's Inbox and the mark is later
used, then we should create a new tab for Inbox's URL and scroll
position, not for the Hangout's URL and scroll position.

As suggested by @mrmr1993 in #1716.