Refocusing window restores previous keyboard-focused state

[JanMiksovsky]

Initial PR, but do not merge yet — there's an open question about unit tests below.

This is a proposed fix for PolymerElements/paper-button#24.

To summarize what I believe is the desired behavior:

• Material Design wants to render focused buttons differently depending on whether they received the focus via the keyboard or a pointer.
• When a window loses the focus, the focused element should drop its focused appearance — but if the window regains the focus, the previously-focused element regain its earlier, specific keyboard/pointer focus rendering.

It seems that all buttons should exhibit this behavior, not just paper-button, so this PR proposes making the fix in iron-button-state. (If that seems correct, I can move the issue to iron-button-state.)

The PR fixes the issue by:

1. Tracking whether the last element to receive the focus had gotten the focus via the keyboard.
2. Detecting whether we're currently doing work in response to a window having been restored.
3. In the case where the window is being restored (point 2, above), we look to see whether the element getting the focus was previously focused via the keyboard (point 1, above). If so, we restore its keyboard-focused appearance; otherwise, we let it render with the pointer-focused appearance.

This PR opportunistically fixes a related, subtle bug in keyboard/pointer focus rendering: if the user switches input modalities while a button has focus, the button's keyboard/pointer focus rendering updates to match the latest modality. If the user presses down on a button with a pointer, then press Space or Enter, the keyboard focus rendering is applied. Conversely, if the user tabs to a button with the keyboard, but then presses the button with a pointer, the keyboard rendering is dropped.

At this point, the core functionality appears to work in interactive testing of paper-button, paper-checkbox, and paper-radio-button, but I'd like recommendations on unit testing this. All existing unit tests pass, but the PR does not yet include unit tests for the new behavior. The new behavior is implicated in window-level blur/focus events, which are not possible to directly test in unit tests, nor does there appear to be support for mock window blur/focus events.