Restructure API docs to avoid duplicate information

[towerofnix]

This means two main things:

• There will be a multitude of comment endpoints spread all throughout the API. Presently we only have endpoints for project pages, but eventually user and studio pages will be migrated to scratch-www and the new API; henceforth, we'll document the comment APIs for those pages as well. However, the APIs will almost certainly be exactly the same across profile, studio, and project comments. But in the current structure, we would end up copy-pasting the same information across each top-level API (/projects/<id>/comments, /users/<name>/comments, /studios/<id>/comments).

• We currently duplicate a lot of information for the sake of consistency, but this isn't particularly fun to read. We should consider collecting information such as "returns an array of comment objects" across two endpoints into a single, more readable sentence. There is also a lot of "Limited to 40 results per request" spread about, which is a little dull to read.

I know that, across both these ideas, what I'm suggesting is to rewrite the docs as more of a guide than an API documentation, but I think it would be more useful in the format. I also suggest keeping an index page - a pure list of endpoints which link to the relevant section in "the guide" and can be ctrl-F'd (e.g. ctrl-F "delete" or "comment" or "user"). (Edit: This would be similar to the existing index page of the API (#34), but a complete list of endpoints rather than a table of contents.)