WIP: Refactoring context and CanvasBackend

The goal of this PR is to make the context more explicit, to associate one context object with each Canvas (or one context object can be shared), and to make this context object active upon drawing so that gloo can be made context aware.

As I changed the code, I also started refactoring CanvasBackend, since it seemed overly complex to me. Before I proceed, we should probably discuss whether this is going in the right direction. cc @Eric89GXL 

My main question is this: the only place where a CanvasBackend is created is from inside the Canvas. Nevertheless, the code seems to jump to hoops to make it possible to set the `_vispy_canvas` object at a later time. Why is that?
Just thinking this might eventually interact with how we want to deal with sharing `OpenCL` / `OpenGL` contexts, too... but we can probably deal with that later.

I do think it's nice not having `gloo` and `app` depend on each other, but I'm not sure it's worth it if it really simplifies things to have `app` depend on `gloo` in a couple of places (like for contexts). It's tough because a context is really the gelling point between GL commands and a given `app` backend, so in some sense it is a shared component. If we have to make one depend on the other and lose orthogonality, I'd rather have `app` depend on `gloo` than the other way around.