Pyfilesystem support+refactor

This adds file system support, and is a refactor of the XBlock codebase as per a longer discussion with Cale, etc. Specifically, 

* We add a directory to XBlocks for reference implementations of standard services, blocks, and fields. In the future, runtimes may provide their own implementations instead (if we decide to do this for fields, this will be a major backwards-compatibility breaking change). 
* We add a process for prototyping services. 
* We add a prototype service+field type which adds pyfilesystem support. We explicitly mark this as a prototype implementation. We'll build this out, and see if there are issues. If there are, we will switch to an interface along the lines of one suggested by @ormsbee 
* We restructure the code such that only some fields are JSONifable, which does not make sense for things like blobs. This will break backwards-compatibility if we decide to do this, but for now, just shows deprecation warnings. 
Cale and I had discussed this at length. The code around services is code in progress/for discussion about how the services will be built. This is not finished. We'd like to get a basic spec in the repo just to get the conversation going. For now, this is just a conversational piece we'll evolve over time. 

In this specific case, all of the kwargs here are optional. We expect the set to grow over time. None are implemented. Probably, once implemented, it will make sense to to have them as explicit parameters, with =None or similar when left empty. I'd like to start writing prototype code where I do pass a type=something parameter, and similar, just to figure out the exact semantics, and this lets us start playing with it. 

A lot of the **kwargs are also there for backwards-compatibility. As we extend the set with optional ones, it means old code doesn't necessarily break. That makes complete sense in a few places where we're passing context and adding bits of context. I'm inclined to agree with you that it probably makes less sense here, but I'd be inclined to figure it out over longer conversation, and change it in a future PR.