[GW] Characterize and document behavior of v0.7.7 argument parser

[glasswings]

While investigating a regression to command-line parsing I realized that I don't yet understand the v0.7.7 behavior, even after reading the manual.

So I'll need to fix that for myself. I would appreciate comments, feedback, or guidance. Otherwise I'll use this issue to report on my progress. (I didn't want to use the upstream issue because I don't want to spam the affected users with "rusty dev still working on it.")

Goals:

• Create at least partially automated test cases that can validate whether argument-parsing behavior is compatible with v0.7.7 (for mothership issue 214)
• Clarify documentation of command line options (for revised manual)

TODO:

• [x] Re-familiarize myself with pdb
• [x] Patch v0.7.7 to trace how the argument parser interacts with the rest of the software
• [ ] automate trace generation
• [ ] Create test-cases for -r and -c
• [ ] Create test-cases for other arguments

[glasswings]

Patched 0.7.7 to trace interactions, I still want to

TODO

• [ ] automate trace generation

So that I can feed a bunch of test command lines into a script and turn those into a test suite for the new parser.

[GregLawson]

I thought I'd describe my pretty elaborate use of the -t and -r options for general interest and to help make sure a similar test case is used to test any new code. I use the -t option repeatedly for 2 purposes: 1) compare library code to unit test code (one test per library function with identical comments on end statements to allow diffuse to synchronize), 2) a Goldilocks display with the working version of each interesting file flanked by a too much (bugs, features) version and a too little (bugs and features) version. This display serves as a kind of bisection micro-surgery scope where each iteration is meant to reduce the difference between the good and the bad versions until the bugs can be isolated and identified. If you don't have multiple branches, the built-in branches main (master) and stash can be used for the good and the bad versions. I use multiple branches: main for versions that pass all my tests, tested for code good enough to run my tests but may fail, and edited for terrible code with compilation errors, infinite loops, and other errors that keep all tests from completing. Below is an example I typically use:

diffuse -r main src/lib.jl src/lib.jl -r edited src/lib.jl \
-t      -r main test/example_data.jl test/example_data.jl -r edited test/example_data.jl \
-t      -r main test/runtests.jl test/runtests.jl -r edited test/runtests.jl \
-t       src/lib.jl test/runtests.jl \
-t      -r main test/notebook.ipynb test/notebook.ipynb -r edited test/notebook.ipynb \
-t      -r main src/main.jl src/main.jl -r edited src/main.jl \
-t      -r main Project.toml Project.toml -r edited Project.toml \
-t      -r main Manifest.toml Manifest.toml -r edited Manifest.toml \
-t      -r main README.md README.md -r edited README.md \