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?
> needing app withouth gloo is less common to needing gloo without app

What would be use-cases of using gloo without app and conversely?

Ideally, yes, I'd prefer app and gloo to be orthogonal and independent, but I'm not familiar enough with the code to tell whether that's possible or not.

Also, let's keep in mind that gloo might be significantly refactored (even rewritten from scratch?) if we start with the GLIR idea. One half of gloo will provide user-exposed functions that generate GLIR calls, another half will interpret them on desktop OpenGL. So maybe we should wait for that to take shape before making any decision...