Glir queue refactoring

Closes #623 

This implememts:

* gloo objects are associated when used, rather than on intialization* 
* There is a `Canvas.context` property which gives access to the GL functions.
* The `canvas.context.glir` is the glir queue for a canvas.
* The `canvas.context.shared' is used by backends to share objects, and also contains the glir parser.
* The `canvas.gloo` and `canvas.glir` are removed.
* The old `vispy.gloo.clear()` also still works; it uses whatever canvas is current at that time. Maybe we should deprecate this. At least discourage it.
* Only one example uses `canvas.gloo`. We should probably modify all to do so.

More on queues: each canvas has a glir queue on its context. There is no shared glir queue. Further, each gloo object has a glir queue too. Glir queues can be associated with other queues (e.g. `program.glir.associate(texture.glir`) so that when the queue gets flushed, the queues of its "dependencies" are flushed as well. This approach makes it possible to associate queues as late as possible, while objects can also be shared (e.g. a texture is associated with both a program and frame buffer). 
Agree we need to limit API changes as much as possible. If you want to delay decision making about the canvas API, then perhaps the examples should be left as they are until then? That way we can get this PR merged soon..