cargo-zigbuild test doesn't pass arguments through properly

[cpick]

Regular cargo test behaves in the following way:

An unadorned -h goes to the "test" subcommand itself:

$  cargo test -h 2>&1 | head -3
Execute all unit and integration tests and build examples of a local package

Usage: cargo test [OPTIONS] [TESTNAME] [-- [ARGS]...]

Inserting a -- separator passes the -h through to the test program:

$  cargo test -- -h 2>&1 | head -3
    Finished test [unoptimized + debuginfo] target(s) in 0.00s
     Running unittests src/main.rs (target/debug/deps/delme_test-e5ac81a61d3b0e6f)
Usage: /Users/cpick/src/delme-test/target/debug/deps/delme_test-e5ac81a61d3b0e6f [OPTIONS] [FILTERS...]

Inserting a second, spurious -- causes the -h to be ignored:

$ cargo test -- -- -h 2>&1 | head -4
    Finished test [unoptimized + debuginfo] target(s) in 0.00s
     Running unittests src/main.rs (target/debug/deps/delme_test-e5ac81a61d3b0e6f)

running 0 tests

By contrast, cargo-zigbuild test behaves in the following way:

An unadorned -h goes to cargo-zigbuilds "test" subcommand:

$ cargo-zigbuild test -h 2>&1 | head -3
Execute all unit and integration tests and build examples of a local package

Usage: cargo-zigbuild test [OPTIONS] [TESTNAME] [args]...

Inserting a -- separator passes the -h through to cargos "test" subcommand:

$ cargo-zigbuild test -- -h 2>&1 | head -3
Execute all unit and integration tests and build examples of a local package

Usage: cargo test [OPTIONS] [TESTNAME] [-- [ARGS]...]

Inserting a second -- causes the -h to be ignored:

$ cargo-zigbuild test -- -- -h 2>&1 | head -4
    Finished test [unoptimized + debuginfo] target(s) in 0.00s
     Running unittests src/main.rs (target/debug/deps/delme_test-e5ac81a61d3b0e6f)

running 0 tests

Issue

The issue is that this prevents arguments from being passed through cargo-zigbuild test to the test program. This includes test name filters, the --nocapture flag, etc.

[cpick]

When testing of the other, similar cargo-zigbuild subcommands ("clippy", "run", and "rustc") I see that they don't provide a way to us a single -- argument to pass options to the underlying cargo subcommand. Instead, they parse the arguments, re-add the appropriate ones, then inject the -- separator between those subcommand arguments and any, unknown others that are intended for the underlying command (eg: rustc, clippy, or the newly-compiled binary).

cargo-zigbuild test just seems to be behaving differently than those others.

[cpick]

I believe messense/cargo-options#12 fixes (and explains the root cause of) the issue.