extract config into a dedicated module

[ndeloof]

What I did

Extracted the config package into a dedicated (sub)module, so third-party component which need to interact with CLI config can use this codebase without inheriting the whole docker/cli dependencies

How I did it

moved code to a at top-level folder and created go.mod

How to verify it

Human readable description for the release notes

introduce github.com/docker/cli/config as an isolated go module for third-party software to access docker CLI configuration files

A picture of a cute animal (not mandatory but encouraged)

[codecov-commenter]

Codecov Report

:x: Patch coverage is 73.12391% with 154 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
...or/github.com/docker/cli/config/configfile/file.go	69.84%	58 Missing and 21 partials :warning:
.../github.com/docker/cli/config/memorystore/store.go	66.15%	20 Missing and 2 partials :warning:
....com/docker/cli/config/credentials/native_store.go	82.22%	13 Missing and 3 partials :warning:
...com/docker/cli/config/credentials/default_store.go	0.00%	13 Missing :warning:
...ub.com/docker/cli/config/credentials/file_store.go	74.50%	10 Missing and 3 partials :warning:
vendor/github.com/docker/cli/config/config.go	91.17%	5 Missing and 1 partial :warning:
...thub.com/docker/cli/config/configfile/file_unix.go	86.36%	2 Missing and 1 partial :warning:
...ker/cli/config/credentials/default_store_darwin.go	0.00%	2 Missing :warning:

:loudspeaker: Thoughts on this report? Let us know!

[ndeloof]

It is already difficult to update / change anything related to the CLI config due to its broad usage internally and externally to Docker.

Sure, but they already do. Not being a separate go module obviously didn't prevented this usage

we should rather be decoupling third parties from the config by providing an alternative

that's still an option, I don't see how this PR would prevent such a move. If you want third-party to access cli/config with a dedicated "officially supported" package, you'll have to somehow deprecate code in docker/cli so they stop relying on this legacy

[thaJeztah]

I need to have a closer look at this one. These packages need sorting out altogether as there's parts that should be considered "exclusive" to the CLI itself (after all, the config-file was the config file for the CLI), and parts that became an implicit "API" (most notably the auth-config, which was embedded in the CLI config). Separate from that, these packages have a MUCH too broad scope. For the auth-config part, I've contemplated having a separate package (which could be for a "plain-text" credentials helper) that's embedded in the config, so that it can be used separate from the other parts of teh config.

But altogether, many parts are currently in an intermediate state, and moving it to a module as-is right now means we'll have to maintain those things forever (SemVer and such); at at least, we'd have to alias the module in the old location, otherwise we end up with issues if (indirect) dependencies expect the old location, which will break.

That's not to say that there's no problem to be fixed, but some work is needed before we can make this happen; in the meantime, it might be better to keep the status quo.