Changes to `GI_VERSION` and `CONTRACTS_VERSION`

[corrideat]

Problem

In Group Income, we have GI_VERSION and CONTRACTS_VERSION, which are used for various things, such as to display them to users and to attempt to reload the app and update the service worker.

There are a few issues with this transitioning to chel serve:

1. The first issue is naming: GI_VERSION is a reference to Group Income, which may not be relevant for other apps. This can be solved trivially by renaming it to something like APP_VERSION
2. The second issue is how GI_VERSION is set. Currently, this comes from package.json, which again may not be relevant for other apps. One way to address this is already part of feat: implement chel DX #64 (not merged at the time of writing), which adds chelonia.json with contract versions. The app version could, for example, be defined there. As chel gets more general and we have app manifests, the app version could be part of the app manifest. Possibly the entire app manifest can be exposed to clients, since it shouldn't have any sensitive information.
3. The third issue, and one for which again feat: implement chel DX #64 is relevant, is that CONTRACTS_VERSION currently works on the assumption that there's a single CONTRACTS_VERSION (i.e., all contracts have the same version, which is due to how contract pinning currently works). However, the goal is having contract versions be separate and possibly unique to each contract, in which case there would be multiple contract versions. This requires both modifying the way the backend works so that the different versions can be exposed and modifying Group Income such that versions are handled per contract instead of globally.

Solution

1. Rename GI_VERSION to something more generic
2. Implement a way to expose the app version (aka GI_VERSION) in a generic way that doesn't rely on package.json
3. Implement a way to expose per-contract versions and modify GI accordingly to support this

[taoeffect]

Yeah I think it's high time we start using app manifests. 👍