Hello folks,

When creating an external shards subcommand (using shards-xxx executable):

https://github.com/crystal-lang/shards/blob/master/src/cli.cr#L101-L105

Noticed it does not pass to the invoked executable the already processed commands like --production, --without-development, --verbose or --quiet, as these were already parsed by OptionParser.

You can confirm this with the following sample executable script:

#!/usr/bin/env sh

echo "args: $@"

Name it shards-dummy, make it executable and place it in $PATH and when invoked, notice certain options where already processed:

$ shards dummy --production --release --static --verbose
args: --release --static

This differs from the behavior of build or run, which passes all - starting options directly to it. Additionally, the impact of --production or --without-development is not validated (something that is done by build and run by doing a check or install).

Since there hasn't been lot of discussion on this subject, I wanted to check first what is the expected behavior:

1. Should all the args be passed verbatim to the custom shards subcommand? Including --production or --without-development ?
2. Should these special shards options be processed first before delegating? (perform a check or install before invoking the subcommand)
3. Should at least the logging options be passed to the subcommand? Eg. --verbose and --quiet

Last but not least, this also impacts --help, as any custom subcommand cannot provide their own help information as this is short-circuit here, but perhaps that is a separate issue.

I wanted to confirm what are the expectations before proposing a PR with changes.

Thank you in advance for your responses!
❤️ ❤️ ❤️