feat(labrinth): rework v3 side types to a single environment field

[AlexTMjugador]

Side types (also known as environment types) are Labrinth's way of representing where a version of a project can be installed (on the client, an integrated singleplayer server, a dedicated multiplayer server, or a combination of these) and where and how much functionality provides to the user (more on the client, more on the server, or both).

Historically, coming up with the right representation for that concept has been a challenging problem. Because projects can integrate into very diverse parts of the Minecraft game with differing levels of functionality, devising a single abstraction that handles all edge cases has proven difficult: the current client_side/server_side (in the v2 routes) and server_only/singleplayer/client_and_server/client_only (in the v3 routes) fields introduce issues for both developers and users. One one hand, developers struggle to write code that makes the right assumptions, e.g. when determining what mods to install on which side for modpacks. On the other hand, users can find it unclear which side type to select when authoring a project, increasing the workload for content moderators and leading to a worse user experience.

This PR lays the foundation for a new approach to side types, centered around a single environment loader enum field for project versions in the v3 routes. The design around this field reflects a consensus reached through an RFC shared in the contributors channel of our Discord server, along with internal planning and discussions (see MOD-275, MOD-48). The values for that field are:

• client_and_server: must be installed on both the client and on a (possibly singleplayer) server.
• client_only: must be installed only on the client.
• client_only_server_optional: must be installed on the client, but may be installed on a (possibly singleplayer) server. The UI should highlight this as a mostly-client mod.
• singleplayer_only: Must be installed only on the integrated singleplayer server. Displayed as a server mod for singleplayer exclusively.
• server_only: must be installed only on a (possibly integrated) server.
• server_only_client_optional: must be installed on a (possibly singleplayer) server, but may be installed on the client. Displayed as a singleplayer-compatible server mod.
• dedicated_server_only: must be installed only on a dedicated multiplayer server (not the integrated singleplayer server). Displayed as a server mod for multiplayer exclusively.
• client_or_server: can be installed on both client and server, with no strong preference for either. Displayed as both a client and server mod.
• client_or_server_prefers_both: can be installed on both client and server, with a preference for being installed on both. Displayed as a client and server mod.
• unknown: fallback value for when the environment is not known yet.

For now, only the v3 routes, which are considered experimental and not subject to versioning guarantees, have had their fields changed. When a project is manipulated using v2 routes, the environment loader field is transparently converted to boolean client_side and server_side fields, which entail some loss, since environment can express more information. Similarly, the automatic translation done in the DB migration proposed in this PR between the server_only, singleplayer, client_and_server, and client_only fields to the new environment field may also change the semantics of how project sides are categorized.

TODO

• Test DB migration with realistic data from the staging environment.
• Review Labrinth integration tests, make sure they do not introduce any regressions.
• End-to-end testing of proper side type handling during project and version creation, edition, retrieval, and search.