feat: Remove the deprecated NamingConventionBinder package and migrate to System.CommandLine

[hoangthanh28]

Related to #756

[wokket]

I've literally just finished a first cut at this change myself... Give me a bit to pull this branch and run some tests, I found some... oddities... in the S.CL parsing while I was working on it

[wokket]

This is showing the same weirdness I saw in my branch earlier... try adding and running the the following test:

    [Fact]
    public void CheckParamBinding()
    {
        // I don't know if this used to work, but it's...weird... now
        var command = new MigrateCommand(null!);
        var result = command.Parse("-connString=localhost"); // oops, missed a dash
        //we'd expect an error here if we looked at result.Errors, no conn string specified
        var cfg = command.GetConfiguration(result); // and definitely not expect this to work missing the required value
        Assert.Null(cfg.ConnectionString); // and even if it was created in error it wouldn't have a value
    }

I get

Assert.Null() Failure: Value is not null
Expected: null
Actual:   "onnString=localhost"

[wokket]

First quick review, generally looking really good though as most of these are nits or discussion points,

[wokket]

This test doesn't seem to throw exceptions when given an incorrect command line? It passes even if passed a commandline with dupe options (eg "-ct=10 -ct=100"). If you look at the ParseResult it has the expected error about a missing --connstring etc so maybe that's a better test?

[hoangthanh28]

Change the test case to Assert the error message instead.

[wokket]

Same thing here, if we can clean up the legacy preconditionals that would be awesome

[hoangthanh28]

This is showing the same weirdness I saw in my branch earlier... try adding and running the the following test:

    [Fact]
    public void CheckParamBinding()
    {
        // I don't know if this used to work, but it's...weird... now
        var command = new MigrateCommand(null!);
        var result = command.Parse("-connString=localhost"); // oops, missed a dash
        //we'd expect an error here if we looked at result.Errors, no conn string specified
        var cfg = command.GetConfiguration(result); // and definitely not expect this to work missing the required value
        Assert.Null(cfg.ConnectionString); // and even if it was created in error it wouldn't have a value
    }

I get

Assert.Null() Failure: Value is not null
Expected: null
Actual:   "onnString=localhost"

System.CommandLine supports POSIX-style "attached value" syntax for single-character options: -c means -c with value . So when it sees the single-dash token -connectionString=abc, it matches the -c alias and swallows the remainder — onnectionString=abc — as the option's value.

[wokket]

LGTM once the conflicts are resolved/tests go green 👍

[hoangthanh28]

@wokket: All checks are passed. CI green now.

Thanks.