Handle POST to /data/fs/[path]

Each line of the body is submitted to MongoDB as a "save" (which is effectively update/insert).

Given the MongoDB model, this actually supports creating a new collection, saving new documents to an existing collection, and updating existing documents (see the README).

All lines are parsed before any data is saved, so nothing is changed if the input is bad. However, partial writes can occur if the MongoDB driver gives an error.

Also added a command `save [path] [object]` to the REPL, and made the `ls` and `cd` commands actually work, for the most part.
I think that all is feasible. 

On PUT: Rename certainly appears to be atomic; it's prohibited for sharded collections and [obtains a global write lock](http://docs.mongodb.org/manual/reference/command/renameCollection/#definition). There will still be a possibility of failure for some of the values, but in that case we can abort before the rename and there's no harm done, and the error can be reported via the single result Task.

On POST: I'm not clear what `FailureCriteria` is good for. Suppose `append` produces a stream of results. Then the caller can consume that stream and decide for itself how successful the call was. How about returning `Process[Task, Unit]`, with one one result for each input value? That way the caller can just count `()`s and failures and decide how to interpret the whole thing. For example, return 200 with a body saying "appended X values", or 400 or 500 with a list of errors. We'll need some published error types for "bad value", "error from backend", etc.

That is, unless you think the caller needs to be able to tell the filesystem/backend when to give up and stop trying to insert values, as opposed to just interpreting the result. I'm not sure what you were thinking those query parameters/headers would allow you to do.