API overhaul and OpenAPI support

[Orhideous]

Hi everyone.

A few months ago I started to sketch out some complete API overhaul (see: #463). The main objectives that I set for myself were:

• simplify the code base for easier support and long-term maintainability;
• leverage battle-tested technologies and approaches as not to reinvent the wheel;
• add ability to generate any client based solely on OpenAPI specification and thus get rid of the routine of writing it manually.

All that is left for me now is just to copy the business logic to the handlers.

So far I already integrated oapi-codegen into codebase. I intentionally left out the old APIs untouched so that they would work in parallel for some time (at least one release). Also, I intentionally designed new API as close as possible to the old one.
This will give time for a more or less painless migration.

@fmartingr What do you think about it? I would be happy to get feedback.

[fmartingr]

My main idea was to create a new API using fiber and separate the logic form the handlers and the database using domains. You can see a draft in #497 (most of the code is the API boilerplate).

It may seem overwhelming because there are many changes, but I think the structure is fairly easy to understand and you can easily see where endpoints are, and since the raw of the logic won't be there it shouldn't pose much of a problem.

Ideally, we will launch this new API in parallel with the current one, to avoid breaking things. We can either expose it as a separate command for now (undocumented) or expose it with the current one so users that are aware of it can use it on their installations.

Fiber also has swagger support