Re-think command storage to associate different implementations of same command with each other

[kangalio]

This issue is a continuation of the discussion in #19.

Problem

Poise currently generates multiple command objects per function, corresponding to each command type (prefix, slash, context menu). These command objects are stored completely separate from each other in PrefixFrameworkOptions and ApplicationFrameworkOptions respectively.

This makes it hard to tell which command invocations belong to the same command at runtime, which is needed for many things:

• a dashboard for the bot to enable or disable commands: you need to know which command entry in the dashboard a command invocation belongs to (this was the motivator for Make commands identifyable #19)
• help command: to display both slash commands and prefix commands in the help menu (Only prefix commands show up in help menu #13), there needs to be a way to avoid displaying commands twice if they have both a prefix and a slash implementation
• command cooldowns ([Feature Request] Command cooldowns #1): cooldowns should apply across invocation types

In #19 we discussed several ideas to redesign how commands are stored in order to fix the issues. But after thinking about each of them and starting to implement a couple in feature branches, none of them seemed great.

I'm currently relatively demotivated to work on this issue because to me it feels like no good solution is in sight. This issue functions as a reminder/placeholder for now, or as a place of discussion for ideas for solutions

[kangalio]

By exploring several of the brainstormed design ideas again, the Arc<CommandId> way turned out to be the most straightforward that also addresses all current design issues