Modularizes API.

This cleans up our mock API code quite a bit. Although our mock API is a temporary section of Rave, I think we'll be doing ourselves a favor with this refactor.

We've got lots of new endpoints to write, and this modularizes things to keep our code DRY. At the end of the day, our API – though a mock – will be quite complicated. By keeping things organized, it'll enable us to more easily make changes and just generally understand what's happening in our API.

These are the biggest changes:

– Each 'module' in the API gets a db file. These files provide our methods for hitting our DB, giving us a place to add transformations, should we need it. In addition, it allows us to reuse these methods wherever we want, without much duplication. For instance, getting data from the user is not only used by the /users endpoint, but also *every* endpoint during authentication!

– Created an Endpoint class for registering endpoints. This makes it dead simple to add new endpoints. No copy+pasting necessary. In conjunction with our db file we find ourselves with very teeny API endpoint files. This is a huge improvement over the pretty convoluted files we had before.

– Adds an ErrorResponse class to send back Errors as JSON in a convenient, consistent fashion.

**Note**: All I did here was update the /preferences endpoint, and add the necessary db file for `users` to handle authorization.

**What's next?** We could convert all of our endpoints to using this system. It'll make things cleaner and easier to read, I think. Also, adding new endpoints is super easy.

There are more refactors that could be done in `core`, too, to make that file much easier to read. We can do that later, though.
Do we really want to register methods that might not exist? Take a look at the current folder structure to see that not all routes have these 4 HTTP methods defined.