Download seperation + Seperate subcommands for client- & server-side mods

[vastoa]

The Problem

I can't seperate the client and server mods from one another without clicking on the mod's link and looking through the text (or checking the tags if the mod is from modrinth). This is pretty annoying in case I want to tell someone what mods they have to download and for general organization. Right now it just feels like a messy "clump" of mods that shouldn't be together.

Your Solution(s)

Defintions

A list of words/identifiers used in this solution to prevent ambiguity and make the wording more compact.

Each of these definitions may be used in their plural form.

Each of these definitions are used in this format to mark that they refer to one of these definitions.

1. Mod

A Minecraft mod that originates from either CurseForge or Modrinth.
A mod's type stands for the "side" at which the mod is needed (client-side, for example).

2. ClientMod

Mod with the type "Client"

3. ServerMod

Mod with the type "Server"

4. ClientServerMod

Mod with the type "Client and Server"

Download Seperation

This makes the management of installed mods easier. For example, in the case that someone wants to download only the server mods to a specific folder, they can use this.

Download seperation is done through either the server_mods_dir or client_mods_dir config. These folders are completely optional.

Mods with no specified type should always be installed into output_dir.

New Subcommands

A new subcommand for each Mod:

• client - Management of ClientMods
• server - Management of ServerMods

The client & server subcommands both manage ClientServerMods.

These subcommands also have their own subcommands, which stay mostly consistent with the commands for the output_dir to ensure an intuitive design.

Some examples are:

• ferium client list - Lists all the ClientMods
• ferium server list - Lists all the ServerMods
• ferium client remove - Remove ClientMods
• ferium server remove - Remove ServerMods
  ...among others

This list is deliberately "vague" in order to prevent becoming outdated as ferium is updated and new commands are added.

To make these subcommands easier to maintain I would abstract the current handler for the output_dir commands and add certain mutable parts that allow you to customize each of the subcommand as needed.

Cases

A list of possible cases and my proposed solutions for them.

The Mod is a ClientServerMod

Store the Mod in both server_mods_dir and client_mods_dir.

server_mods_dir or client_mods_dir are empty

Store the correspondant Mod in the output_dir.

Ferium can't figure out the type or the type is "Client or Server"

Show a multi-select context menu (with a descriptive title) that has the following selectables:

• Client
• Server

If the user chose nothing, the result should be an empty array.

Store the result (as an array) under the type key in the Mod's config.

The Mods in the current profile don't have a type specified

Might happen when a user updates ferium from a version that didn't have it yet

If either server_mods_dir or client_mods_dir are configured, then, on the next run of the ferium upgrade command, fetch each Mod's type and store it.

[theRookieCoder]

Added to #155 (filters), sorry but your solution is far too complicated and would end up confusing new users.