Add argument parsing, add_console_command and other features

[tqwewe]

This PR is a breaking change and adds a lot of things including:

• Argument parsing
• Registering commands with app.add_console_command
• Derive macro for defining console commands with structs
• Console command help information and usage
• ConsoleCommand system parameter
• Built in help, clear and exit console commands
• Command history with up and down arrows

There's a lot to go through, the best place to start would be to clone the fork and run the examples.

Basic example of defining and handling a console command:

/// Prints given arguments to the console
#[derive(ConsoleCommand)]
#[console_command(name = "log")]
struct LogCommand {
    /// Message to print
    msg: String,
    /// Number of times to print message
    num: Option<i64>,
}

fn log_command(mut log: ConsoleCommand<LogCommand>) {
    if let Some(LogCommand { msg, num }) = log.take() {
        let repeat_count = num.unwrap_or(1);

        for _ in 0..repeat_count {
            reply!(log, "{msg}");
        }

        log.ok();
    }
}

app.add_console_command::<LogCommand, _, _>(log_command);

This code snippet will register the command when the user enters help and help log (using doc comments), and will only execute if the arguments are parsed successfully into the correct types.

[alice-i-cecile]

First pass on code quality looks good! I'm generally impressed with the features and ergonomics of the design.

[RichoDemus]

Thanks for the PR and for all the comments, I'll try to take a look this week!

[tqwewe]

Made some updates including:

• Command history with up and down arrows
• Fixed terminal scroll width not expanding to fill window
• Fixed scroll glitching when you scroll up
• And some other small updates

[tqwewe]

I also tried tackling the issue #2 of blocking input when the console is open by clearing the input events, but doing so made the console terminal break too not allowing you to press enter.

This issue is a difficult one to solve which I'm not sure is really possible.

[RichoDemus]

This looks very good, thanks a lot for your effort. I'm very positive to merging this, I just have a few things

1. There are some pieces of code that are commented out, are they old things that should be removed?
2. So right now the command description is generated from the comment, I think that's a bit to "magical" and that it would be a lot more clear if it was a macro parameter just like name is now, what do you think?
   I also think that maybe it could be desirable to be able to actually write a comment for a command without that being exposed to the end-user

[tqwewe]

Thanks for the feedback!

1. There are some pieces of code that are commented out, are they old things that should be removed?

I had a look through but couldn't really see any old code commented out. Perhaps you just saw my doc comment examples and mistook it for old code I commented out?

The only commented code I could find, I've removed in this commit: tqwewe@5458546

2. So right now the command description is generated from the comment, I think that's a bit to "magical" and that it would be a lot more clear if it was a macro parameter just like name is now, what do you think?

I agree that it's a little magical, but I think that's just part of the power of Rust macros. I don't really feel that it's overly magical to confuse the user though, it's just a feature of macros imo.

If it was an attribute, then what if you also wanted doc comments? It might be a little frustrating to have to write your info twice.
Eg:

/// Prints given arguments to the console
#[derive(ConsoleCommand)]
#[console_command(name = "log")]
#[console_command(help = "Prints given arguments to the console")]
pub struct LogCommand {
    /// Message to print
    #[console_command(help = "Message to print")]
    pub msg: String,
    /// Number of times to print message
    #[console_command(help = "Number of times to print message")]
    pub num: Option<i64>,
}

I feel that this just adds too much boilerplate when the help would almost always be the same as the doc comment right? And you also have the annoying thing of the docs going out of sync with the help attribute, whereas having it all as a doc comment kind of kills two birds with one stone without many disadvantages.

I also think that maybe it could be desirable to be able to actually write a comment for a command without that being exposed to the end-user

If that's true then it is indeed a down side.
Another option is to use doc comments by default as it feels much cleaner, but also support overriding the help through the help attribute.
Eg:

/// Here is a doc comment for my Rust code
#[console_command(help = "Message to print")]
msg: String,
/// Number of times to print message
num: Option<i64>,

I'm curious to hear if @alice-i-cecile has any thoughts on this?

[RichoDemus]

Oh yeah, and cargo test fails
I should add some simple github action ^^

[tqwewe]

I've just fixed the doc tests, so it should all be passing now