Make swagger UI sections more logical for API consumers: regroup and separate public/private endpoints

[corneliusroemer]

@anna-parker and I just realized we'd independently been bothered by our swagger UI grouping being not very logical for API consumers, the current grouping is based on code organization, which is nothing API users should have to think about.

Certain backend APIs are written for public consumption (e.g. submission) while others are not really intended to be for public consumption (e.g. get original metadata). We should group things into stable and unstable APIs (private coming with no stability guarantees, if API users want them to become stable they should contact us).

Tasks:

• Indicate authentication requirements correctly
• Grouping into logical sections (submission vs. getting data vs groups vs preprocessing etc)
• Public vs private (endpoints for certain privileged users, e.g. preprocessing)
• Stable vs unstable APIs (the ones that we think people shouldn't [want to/have to] use we mark as unstable)