Reduce risk of MongoDB query selector attacks

For Bounty 229: ["Defend our API against query selector attacks"](https://assembly.com/buckets/bounties/229)

This is the result of investigating how this style of attack would affect the existing API. There are three primary places that unsanitized user input is being used, via directly using `request.body`, `request.query`, and `request.params`. 

Params are always strings, so this should not be susceptible to this style of attack (though there may be others and some more validity checking would be good IMO, especially in a language with no type checking). Query values should generally be strings **if** express is configured in "simple" mode for its query parsing, which is NOT the default. I've changed this setting in this PR.

Finally, the middleware being used automatically parses both JSON and multipart forms and as such any direct access to `request.body.something` would be vulnerable to these query selector attacks. 

I've introduced some middleware that recurses through request.body looking for any objects with keys starting with a $ sign. If there are any, then the middleware returns a 403 Forbidden to the end user. I've written tests to test various types of objects and make sure we catch all these $keys. Additionally, I added a test to verify the 403 behavior when sending a JSON request body with this type of key.

In this PR there are a few changes of findOne(_id: id) to findById(id) for consistency.

This is the most Coffeescript I've written at once so if there are things I could improve on I appreciate the feedback. Some of the code could perhaps be organized differently but I'm not sure what the project conventions are.
That was my initial implementation but had a change of heart. I'll do whichever you prefer but figure I should explain my rationale:

- I fear that removing the object could make this harder to catch in development or production; if we *break* the request/response cycle with a descriptive error message then at least someone who tries to use this in the future will know what's going on; if we were to change it I'd hope for some logging at least if a bad object is submitted

- if we remove the object, it makes it harder to test if the middleware is actually working as I implemented in `test/server/routes/api/users.coffee` (i.e. check for a forbidden response)

- if the checkKeys method becomes a checkAndCleanKeys method, or something like that, it also makes testing it more complicated and its interaction with the implemented middleware weirder (i.e. do we throw an error? return true/false? it'd be good to be able to know in `server/index.coffee` the result and the most elegant way seems to be to return the bad object)

Again, open to changing but appreciate you considering my thought process on it.