V7: Extract System.Configuration.ConfigurationManager support into its own package

[dimension-zero]

Spinning out of #308 (rename of Argu.MSConfig → Argu.Extensions.Configuration) and #234 (Numpsy's experiment).

Proposal

Move the System.Configuration.ConfigurationManager reader out of Argu core into its own NuGet package (e.g. Argu.Configuration.ConfigurationManager or similar). The core package then stops carrying a transitive dependency on System.Configuration.ConfigurationManager, which in turn pulls System.Diagnostics.EventLog and the rest of the legacy System.Configuration jungle.

Why

• Consumers on the modern stack (Microsoft.Extensions.Configuration via Argu.Extensions.Configuration from feat(ConfigurationReader): FromEnvironmentVariables(prefix), FromMicrosoftConfiguration #308) do not need ConfigurationManager and should not pay for it.
• @Numpsy already prototyped the move in Extract Argu.Extensions.ConfigurationManager #234; the question is mainly naming and timing.
• @bartelink in Extract Argu.Extensions.ConfigurationManager #234: "a change to externalize the ConfigurationManager would be a welcome development" and is V7-merit material alongside the existing obsoletions on master.
• Pairing this with feat(ConfigurationReader): FromEnvironmentVariables(prefix), FromMicrosoftConfiguration #308's naming decision is useful — landing both at once cross-validates that the package taxonomy makes sense.

Scope

• New package referencing System.Configuration.ConfigurationManager.
• Existing AppSettingsConfigurationReader moves to that package (likely behind the same API surface or a thin shim).
• Argu core stops referencing System.Configuration.ConfigurationManager.
• V7 breaking change with migration notes (one-line PackageReference addition for existing consumers).

Open questions

• Final package name: Argu.Configuration.ConfigurationManager, Argu.AppSettings, or something else?
• Keep the legacy ConfigurationReader.FromAppSettings() static on core (delegating via reflection) for one release, or hard-break in V7?
• Do we ship feat(ConfigurationReader): FromEnvironmentVariables(prefix), FromMicrosoftConfiguration #308's Extract Argu.Extensions.ConfigurationManager #234's appsetting.json and NET5 #171's work as one coordinated V7, or staged?

Refs #234, #308, #171.

[Numpsy]

Keep the legacy ConfigurationReader.FromAppSettings() static on core (delegating via reflection) for one release, or hard-break in V7?

One of the questions from the original change was about this direct call to FromAppSettings() inside Argu itself:

Argu/src/Argu/ArgumentParser.fs

Line 218 in 198f4d5

| None -> ConfigurationReader.FromAppSettings()

If it's removed, then that needs to do something else

[bartelink]

Yes, that's the main issue - providing a standard clean way to parse given:

• a particular set of sources, i.e. AppSettings/ConfigurationManager (potentially in future, external-Async)
• a command line (and/or defaulting to getEnvironmentCommandLineArgs which I think should go)
• some specified order of precedence

Atm, Parse, ParseConfiguration, ParseCommandLine overlap in various ways that I can't say are totally obvious to me.

I'd venture that the dominant consumption mode is to only work off commandline inputs, so maybe if all 3 entrypoints got Obsoleted in favor of two explicitly named ones e.g.

1. ParseArgv(mandatory argv, NO reader argument, no fallback to anything external), i.e. a new name that forces people relying on Parse falling back to AppSettings to either opt into losing that fallback, or switch to ParseWith [and have to reference the package to do so].
2. ParseWith(optional argv, [paramarray] mandatory IReader), then the IReader can be one or more of Argu.Extensions.AppSettings.AppSettingsReader(), Argu.Extensions.Configuration.ConfigurationReader() (maybe shorter namespaces and/or have the readers in the extension packages be placed in an Argu base namespace).

(Obviously with better names)

This also lets one provide a clear way in which an env var reader (with or without prefix) plugs into the seatch.

This would also make the tests clearer - right now there's a big slab of tests with no clear breakdown between whether it's about the the primary behavior, fallback logic or reader specifics - if those aspects can be made orthogonal internally then the tests get clearer too. (i.e. each extension module can unit test its reader to destruction, then demonstrate that they can integrate with the fallback mechanism, and you're done - the core package has already proven that it works with a commandline only/and/or a fallback)

(I should declare my bias here too: The less stuff the core does the better from my perspective. I've never knowingly used the AppSettings support, and do all fallbacks to env vars as explicit GetResult(Param, () -> Config.ReadEnv "Param") usages of the PostProcess APIs. I'd love if there was a clear sample and/or mechanism where the usage rendering and the parsing behavior work together to document and fall back consistently i.e. let me say, for this arg, there are 2 sources - commandline can override and wins is specified, then check the env var named "X", finally falling back to app settings "Z" - the devil is in the details though - if the env vars need prefixing and there's some complex naming scheme for the AppSettings, how do you render that? For all I know it can already be made to work, but I always punted and said "well if I put this text here in the helpstring and this one liner of logic that I can eyeball then I am done and I can write the actual feature" !)