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.
For HTTP PUT, that is, atomic overwrite of a file, it's essential the request succeed fully or fail without changing anything. To achieve this guarantee, I think you insert in a temp collection, and if there are *any* errors, you delete the temp collection, but if there are no errors, you atomically rename the temp collection to the requested file name.

For HTTP POST, there's no easy way to implement the above semantic because there's no atomic "move the contents of this collection into this other collection". Also, when adding to a file (distinct from overwriting), users will eventually want the ability to see reports on any failures, and, indeed, to define what "failure" is, e.g. as a percentage of the entries being uploaded. Thus I think for HTTP POST, it's more natural to collect and return any failures. If there are "enough" failures, you'd return a 400-level error code indicating the request is bad. If there are only a "few", then you'd return a 200-level error code with a list of failures.

For now all this could be hard-coded, but eventually the API should support user-defined criteria for success/failure, e.g. as an X-header or as a query parameter.