Allow Nodes to use the keyboard state

[tcstewar]

This lets you create keyboard controls in the gui. All keyup/down events are sent back to the server, and we keep track of which ones are currently down. You can access this information via a new magic variable __page__, which gives you the current nengo_gui.page.Page object.

As a simple example, this lets you do this:

    def ctrl_node(t):
        if 'w' in __page__.keys_pressed:
            return 1
        elif 's' in __page__.keys_pressed:
            return -1
        return 0
    stim = nengo.Node(ctrl_node)

We keep track of both the keys_pressed and the key_codes_pressed, so both are available.

It should be noted that this is a very different approach to doing interaction with Nodes than was done in #727. This is, I think, simpler, but it does mean that we're always tracking keyup/down info.

[bmorcos]

We hoping to use this in a NengoFPGA example, it would be swell if this could get merged soon.

I'm not sure if I understand the GUI enough to do a proper review, but I've used this with @xchoo's code successfully.

[jgosmann]

I probably could give this a review soon-ish, but I'm not sure that this would speed up anything given the usual turn around time on Nengo GUI PRs.

[tcstewar]

I think the only big outstanding issue with this PR is whether to use the __page__ magic variable approach. I'm not particularly happy with having that magic variable, and I think I'd prefer something more like this:

import nengo_gui
gui = nengo_gui.Interface()

with nengo.Network() as model:
    def ctrl_node(t):
        if 'w' in gui.keys_pressed:
            return 1
        elif 's' in gui.keys_pressed:
            return -1
        return 0
    stim = nengo.Node(ctrl_node)

The only reason I'd lean towards something like this is that it gives us a clear way of adding other features like this (gui.dt = 0.0001 or gui.backend = 'nengo_ocl' or even maybe @gui.on_start).....

(for clarity, I do not think those other features should be implemented as part of this PR, but this syntax would at least give space for those sorts of features and might be a little less magical than the __page__ variable)

[tcstewar]

Well, since I didn't manage to implement the alternate syntax before the summer school, I'm going to merge this as an experimental feature. Thank you for all the feedback and discussions on this feature along the way!