Adding support for an argument tree rather than a simple list

[SimplyLinn]

Is your feature request related to a problem? Please describe.
Commando is pretty powerful with its prompting for valid arguments and stuff, but there's a limitation to simply using a list for arguments; You can't have arguments that depend on what the value of the previous argument was using. Sure, you can get around this by simply accepting anything as arguments and do the argument parsing yourself later, but if you want the functionality that Commando provides you have to replicate it yourself, and I do feel this could be in scope for something Commando could handle automatically

Describe the solution you'd like

• ArgumentInfo will be extended with a new property, Possibly named subArgs or something, that takes a Map-like object, potentially an actual Map.
• The argument to use will be selected based on the parsed value of the parent argument, used as a key in the subArgs map.
• If the parsed value is not found within subArgs, the subArgs will simply be ignored. (The functionality of enforcing that the argument is part of the subArgs can be done with the validate function).
• The value of the subArgs map is a list of further ArgumentInfo object, which in turn can contain its own subArgs.
• When a branch of sub arguments have been resolved, we backtrack to the next argument in the last traversed list, and resolve that if there are more arguments to resolve, otherwise we backtrack to the list one step further up in the subArgs tree.
• Once the entire tree has been parsed, and validated, we move on to executing the command.

I'd also like to propose another property of the ArgumentInfo object (possibly named subParse) that if specified will, prior to the passing of the parsed value, transform it. Say the parsed value is a member, and your map contains member ID's as keys, your subParse function could be (member)=>member.id.

Describe alternatives you've considered
I've considered subcommands, which in theory could achieve similar results. But those are a lot more bulky and have been brought up previously and been rejected.

Additional context
The usecase I'd like this functionality for is something like this:
!setStuff <key> <value> where key can be one of "someRole", "timestamp" and "enabled".

Each of these keys have different types for <value>, one is a discord role, one is an integer, and one is a boolean. Using a tree, where we select the next argument based on the value of the current one would enable me to define 3 sub-arguments, each with a different type, and have Commando do the validation and prompting just as if I only had one type of value.

[SimplyLinn]

Actually, now that I think about it... This still allows for ambiguity as to which argument in the tree an argument passed to the command should map to:

Say if a subArg has an optional argument, and there's another argument in the list of the current argument. Should the current argument in the passed arguments map to the optional subArg or the next argument in the list? One solution to this would be to disallow default values for subArgs

[SimplyLinn]

Not to nag or anything, but it's been 15 days since this request got its label. Any input/opinion on this idea from the maintainers? I'm happy to implement it myself, but it'd be a non-trivial change of the internal structure of Commando and I'd rather not spend a lot of time working on this feature just to have the pull request, in the end, being rejected based on that "nah, we don't actually want this feature at all"