implement response signing for manager and patches routes

[uvindusl]

This PR implements cryptographic response signing for the Manager and Patches services. By adding { data, signature, certificate } wrapping to our API responses, we allow clients to verify the authenticity of the release data.

#205

[oSumAtrIX]

This looks good for the most part, however it expectedly introduces breaking changes. Now, there is a further advancement to this which inlines both, the signature and certificate into the .rvp.

This solves decoupling, the file would ship the signature, the certificate for TOFU and the rvp. It would also reduce the obligation of the API here to deliver these three tightly related components together. Additionally, one could distribute the rvp and let it be consumable without having to deliver the certificate and signature separately. The signature is generated at build time of the rvp, and probably the certificate for it should as well. I am not sure how the build system would have to look like for this purpose though.

Since this PR introduces a breaking change, but there is a near advancement which would also cause a breaking change, it would be better to directly implement the advancement.

However this would require looking into the patches side of the matter, specifically https://github.com/ReVanced/revanced-patches-template.

As explained earlier, the simplest form of satisfying the requirements doesnt require a certificate at all, but the public key of the signing key. In other words, the build system could possibly generate the rvp, the signature and the corresponding public key. Currently the build system uses the native signing plugin which does not feature something like this. A wrapping layer to extend the signing plugin also sounds hacky. I am not sure what the "correct" approach to this is. Should the build system include the public key at build time, or should it be provided to the build system manually?