feat: command args feature

[VALERA771]

Description

Describe the changes
Adds a new class (CommandArgs) which provides easy access to all command's args with conversions and stuff

What is the current behavior? (You can also link to an open issue here)

What is the new behavior? (if this is a feature change)

Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)

Other information:
Regex is written with AI cuz I'm a dumb-dumb, thus requires testing
Also I'm planning to add some more cool features to this class but as for now backbone of it is already done

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentations

Submission checklist

• I have checked the project can be compiled
• I have tested my changes and it worked as expected

Patches (if there are any changes related to Harmony patches)

• I have checked no IL patching errors in the console

Other

• Still requires more testing

[Unbistrackted]

I actually like this, I hate creating commands cause I always have to do the checks and that what takes the most ammount of time

[Someone-193]

All we really need is somebody to test this b4 we merge this

[warquys]

The idea of .doodes is an state machine allowing you to pars all the argument at once and then check if all is ok.

//Inside a command
var cargs = CommandArguments.Parse(args); //turns ArraySegment<string> into CommandArguments instance

Player Target = cargs.GetPlayerAt(0); //Gets a player by id/name from the argument 0 or null.
int Health = cargs.GetIntAt(1); // gets and parses an int from argument 1 or null

if(!cargs.Ensure(out response)) // will make sure that all arguments that are retrieved through GetPlayerAt, GetIntAt, GetFloatAt, ect are valid and not null. If they arent, it returns false and sets response to something like:
//"Argument {x} should be a {type}"
   return false; 

//Then we can use the arguments normally 

Target.Health = Health;

His exemple

[VALERA771]

If we implement original suggestion, we'll have to store internally types and indexes. I assume it might be easier for devs to just run one function which will just return response if one of the arguments is incorrect. But current implementation allows devs to use Try methods to get a value and check if it's not null and matches provided type

[Someone-193]

I'm with Valera on this one, I think having the Try methods is good enough, if you want, write your own state machine on top of CommandArgs in your own plugins. But as it is right now, devs can just return their own error messages if TryGetX fails