feat: Restructure endpoints to /manager and /patches routes

[oSumAtrIX]

Issue

This is a followup on

• feat: /manager and /patches endpoint #50

Currently, the compose version of ReVanced Manager is planning support from multiple sources. The idea is that ReVanced Manager can use multiple patch bundles simultaneously. For that, it has to allocate a specification for vendors of the patch bundles that is semantically identical to the API but still a separate implementation. ReVanced Manager refers to that as "repos". Each repo delivers its patch bundle. The bundles can be added by entering the repo URL. ReVanced Manager then downloads the patches and uses them in combination with the patch bundle configured in the API. Because, semantically, that concept is identical to the API, it makes sense to abstract the API into a /patches route, which satisfies the concept of repos on the side of ReVanced Manager.

An additional issue is that with #161 the API provides an API to get metadata about apps. Because a whitelist is necessary to prevent abuse of the API, ReVanced Manager would not be able to use the API for patch bundles that support packages outside of the patch bundle supplied by the API. This means the apps supported by these patches would not have any display name or icon.
To solve this, the API to fetch app info would be moved into the /patches route. As this route replaces the need of the "repo" concept on the side of ReVanced Manager, and ReVanced Manager would be able to add and use patch bundles using the /patches route API directly, it would also be able to request the patch bundle's specific API for app info.

With the API restructure, a specific /manager route would be created with APIs primarily useful for frontends like ReVanced Manager. The route would have APIs such as updating ReVanced Manager, whereas the /patches route would be used by frontends such as ReVanced Website or ReVanced Manager to provide its main patches bundle. The website would ask for the serialized version of the patches to display the list of patches.

Next to those two APIs, ReVanced API would also have various APIs directly under the / route that are agnostic to the other two routes above. It would feature APIs such as that to get the team members, the about and links. These would be used by ReVanced Manager and ReVanced Website and other general purpose API clients, respectively.

Motivation

The restructuring is motivated by the following:

• The restructure simplifies the purpose and structure of the API. It is clear what purpose each API serves, and general APIs such as links or team members wouldn't be under the same route level as, for example, the patches, as they are semantically distinct
• The app info API can be whitelisted; ReVanced Manager can still show app info for any bundle by requesting the bundle's API for the info, respectively
• ReVanced Manager will be able to drop the "repo" concept, semantically identical to the patches endpoint from the API

Without these changes, ReVanced API can not whitelist the app info API. It would be subject to attacks or improper use or prevent ReVanced Manager from displaying app info for patch bundles other than the one the API supplies.
Without these changes, ReVanced Manager requires a separate "repo" concept to support third-party bundles next to the main bundle simultaneously, whereas both could be the API's patches API.

Additional context

Since this change implies that the repo concept of ReVanced Manager is dropped in favour of the API, it would cause an overhead for patch vendors to host the API. The repo concept is static and easy to use because it does not require hosting the API. Luckily, this is not a problem, as anyone who does not want to host the API can statically render the APIs from /patches, including the app info API.
A convenient setup could involve a workflow that runs the promised CLI of ReVanced API (or other means) to generate static files and use these instead of the API. This way, they could publish patches and app info statically for each release of their patches, just like with the "repo" concept.

To proceed with this issue, we must first determine which APIs can be combined in which route. Another question is specifically for the app info endpoint, as the currently proposed design involves dynamic query parameters, considering we want to be able to render a static API using CLI.