Break down of the commits

I think it makes sense to review this per commit. The first few ones are Obliie's, and the merge commit, so I will omit those and only explain mine.

First commit: WIP: Note Slash Command

I needed a proof of concept. I took the Note command because it seemed simple enough, but not too simple.

Started with a command I am familiar with, the ban command, started moving code parts around so it would be ready to extract the business part to an actualBanCmd function, realized it was probably too big for a proof of concept so picked another command instead (but what I had moved in the ban command made sense so I kept it)
Extracted the business code to an "actualNoteCmd" function so that the slash command file and the message command file could call the same code
Had to rename the type of message commands, to specify they are message commands since they are not anymore the only type of command in the plugin, which modified every single command file
First modification of the sendSuccessMessage and sendErrorMessage functions
Introduction of a "context" concept, where a lot of functions now don't know whether they are called by a message command or a slash command, so they can take either a text channel or an interaction (because at that point the context was used to reply only)
We decided with Dragory that since Zeppelin definitely has more than a hundred commands, and since Discord's maximum amount of slash commands for one bot is 100, we are going to make each Zeppelin plugin a slash command group (at least when it's relevant) and each Zeppelin command inside of that plugin is going to be a slash command in that group.

Second commit: feat: first batch of emojis 🎉

I can't believe I am noticing just now that I had a brainfart while writing the name of this commit... I was so glad I wanted to name it "First batch of slash commands", but then I felt like it needed an emoji. I guess somewhere along the line I typed "emojis" instead of "slash commands" :') . But yeah, this is supposed to be the first batch of slash commands.

Following the note command's proof of concept, I did the same thing on all the other commands of the ModActions plugin. It was a huge amount of work and I had to modify a bunch of util functions!

New util functions isContextInteraction and sendContextResponse. A lot of functions need to reply to a context, and writing the same "ifs" everywhere doesn't make sense when I can just make a function, so that's how sendContextResponse was born. And in order to know what I should do with a context to send a response, I mainly needed to know if it was an interaction or not, hence the other function. Context also got the "User" type because there is a util function somewhere that can take a User as well as a TextBasedChannel, don't ask me which one I don't remember, but it made sense since User.send() is a thing, so I added it. Edit: I found which one. It was createPaginatedMessage().
Every command got transferred to its own neat folder. Most command folders have only two files, a SmthMsgCmd.ts one and a SmthSlashCmd.ts one. Some have more than two.
"actualCommand"s really started popping out in the functions folder, so I gave them their own cozy subfolder
When mods use Zeppelin, they only see a single "cases" command, even though there are technically two in the code. For message commands, knub makes it work to have two commands with the same name because their signature is different. For slash commands, that was impossible. I had to somehow merge those two. And that required changing GuildCases.ts a bit to offer new features to the end result!
Did you know that a slash command group has a character limit??? Well if you did, you're a nerd. I didn't. Discord adds up the amount of characters in the slash command group's name and description and all of its slash command children's names, descriptions, option names and descriptions, and if all of that is more than 4000 characters, it is denied. For that reason, I had to find out how to cut down on the amount of characters. I noticed that a lot of it was probably the three attachment options a lot of commands had, so I made a constants.ts file that would hold two constants: one for the amount of attachments each case creating command (like ban, warn, mute, etc) has, and one for the amount of attachments each case updating command (there's only one, update) has. With that, I could easily switch it for every single command and make sure to not hit the limit.
Slash command's attachment type options can only take one file. So I made helper functions. One of them generated as many attachment slash command options as you want, the other one retrieves as many attachment slash command option values as you want. They are used throughout the slash commands that need attachments.

Third commit: Added Discord attachment link reaction, fixed emoji configuration and moved util functions

This one felt like it would get the best of me, it seemed so easy but ended up being so much work. Discord attachment links are only valid for a limited amount of time (I thought it was a month, but turns out it's like two weeks? Or maybe a week only? But anyways they said it could change so yeah), so basically using those links for case archives is no bueno.

Added a "getContextChannel" util function because a lot of functions need to get a TextBasedChannel from a context.
Context had to accept messages too, for attachment handling reasons
Added a function to append the message link to a case reason, so that way the message link is stored in the case archives, and that one will last forever, unless someone deletes the message.
- If this function receives a message, coolio, just adds the message link, ezpz lemon squeezie.
- If this function receives an interaction, oof. There is no message link for interactions, so we have to do something about that.
- Added a configuration so that server admins can decide where Zeppelin stores attachments
- This function will use that configuration and repost the attachments to that channel, if it does not exist it will repost them to the current channel (the interaction.channel channel)
- Reposting the attachments means a message now exists, so the function uses that message link and adds it to the case reason
For each function that touches a case reason, the reason sent to the user has the old fashioned attachment links so they receive the images, and reason stored in the archives has the message link
Added a configuration to decide what to do if Zeppelin detects that a Discord attachment link was manually added to a reason (nothing, warn or restrict)
For each function that touches a case reason, if that reason contains a manually added Discord attachment link,
- If the configuration is "none", the bot keeps it in the reason and stores it as if nothing was detected
- If the configuration is "warn" or null (because that's the default), the bot will send a message saying that there is a temporary attachment link in that reason and that it's better to upload attachments with the command, but will still proceed with the command
- If the configuration is "restrict", the bot will send the same warning as previously but will also inform the user that the command was canceled, and will just stop there.
Fixed success and error emoji configuration
- Added an error message if they are still configured in the root of the yaml, explaining how to properly configure them instead
- Added a "common" plugin that can receive the configuration for those emojis
- Moved "sendErrorMessage" and "sendSuccessMessage" to that new plugin to avoid a circular reference
- Making that move basically had me modify every single typescript file in the universe, but don't worry about my mental health it's fine I'll just send you my therapy bill

Conclusion

This is a huge pull request. I was not able to test everything and make sure there are no bugs. I tested what I could, obviously, but I wouldn't be surprised if we were to find a lot of bugs in this, even I am not enough people to test this many cases.

I think what I will do is merge this on VANGUARD, and let our mods do the testing. They will probably find bugs, I will fix them in this PR and merge again on VANGUARD. Eventually, we should have a pretty stable version!