V7: Move structure check off the constructor, distinguish ArguException vs ArguParseException

[dimension-zero]

Spinning out of #306. Captures @bartelink's counter-proposal verbatim — the intent of #306 was a TryCreate returning Result<_, exn>, but the deeper observation is that the constructor / Create running structure validation eagerly is the wrong shape, and a TryCreate wrapper becomes obsolete-on-arrival once that is fixed.

Proposal

1. Create never throws. No structure check at construction time.
2. Lazy, cached structure check on first Parse. Any parse entry point runs the check once (memoised on the parser instance) before doing input parsing. Programmer errors (structure) and user errors (input) end up on the same code path the user is already prepared to handle.
3. Opt-out escape hatch. Create(skipCheckStructure=true) for guaranteed non-throwing construction. XML doc spells out the contract: caller must have run ArgumentParser<T>.CheckStructure() in a test for that schema, otherwise behaviour is undefined.
4. Exception taxonomy stays:
   • ArguException for structure failures (programmer error, raised by the lazy check unless skipCheckStructure=true).
   • ArguParseException for input failures (user error, raised by parsing).
   • Tutorial + samples updated to make the distinction explicit, including the recommended host pattern (try/with only around Parse*, not around Create).

Why now

• The eager-validation-in-constructor surprise is the root cause of feat(ArgumentParser): Add TryCreate returning Result<_, exn> #306's request.
• @bartelink: "I didnt know the config validation runs as part of construction of the parser."
• V7 is already implied by the obsoletions on master (see V7: Extract System.Configuration.ConfigurationManager support into its own package #325 / Extract Argu.Extensions.ConfigurationManager #234) so the breaking change cost is partially amortised.
• A Result-shaped path can land as a follow-up after this — it becomes trivial once Create itself can't throw.

Out of scope (follow-up)

• TryCreate/Result API (revisit after this lands).
• Per-V7: Extract System.Configuration.ConfigurationManager support into its own package #325 ConfigurationManager extraction (separate V7 change).
• Any perf changes to the structure check itself; lazy-but-cached should be enough.

Refs #306, #325.

[bartelink]

Looks great, thanks for taking the time.

My only concern is that I'd prefer for discussion of catch/Result stuff be kept at least as a separate issue (see this discussion where I'm ironically putting it in somewhere despite my personal beliefs being in line with gusty's ones - it just causes trouble, and the workaround to catch things yourself if you insist on going down that road is not terribly onerous).

Most importantly though, if there's to be any catch/result variants there needs to be a good demo sample and a tutorial - for me step one is to show a canonical main that cleanly handles parsing, then running and/or printing a message and exiting. Then one can work from there proposing that main will be improved in this way if this support function is added etc...

@nojaf anything to add?

[nojaf]

Seems reasonable, but no strong opinion as I'm not in the weeds on all this.