refactor(parquet/cmd): replace uses of github.com/docopt/docopt-go

[thaJeztah]

The github.com/docopt/docopt-go repository has not been maintained for many Years; replace it for stdlib flags, which is slightly more code to write, but removes the un-maintained dependency.

Rationale for this change

What changes are included in this PR?

Are these changes tested?

Are there any user-facing changes?

[zeroshade]

Should we potentially shift to using https://pkg.go.dev/github.com/alexflint/go-arg#section-readme instead then? It might simplify things over using the native flag stuff.

[thaJeztah]

I intentionally kept this PR minimal / close to the existing functionality as my intent was to remove the dependency, and assuming that adding new flags / features to the CLI would be "rare", so a slight bit of extra code to define the flag would be a one-time change, and wouldn't add much maintenance after that.

But it all depends a bit on what the scope of this project and the command-line binaries is.

For example, I know that containerd (https://github.com/containerd/containerd) and BuildKit (https://github.com/moby/buildkit) both provide a CLI (ctr and buildctl) but for both projects, those CLIs are called out to be for debugging and testing purposes; they're intentionally not a polished CLI and bare-bones in many areas, because the main purpose of both projects is to be used as either a library module, or as a component in a product (so the product using it as component or library can provide the "polished" experience).

If the intent is for these binaries to be used for debugging, testing, and/or development of the code in the repository, then I'd keep them bare-bones, and try to minimize their effect (i.e., avoid adding extra dependencies that are only used for a development tool); at least if they are part of the same module also used as library, so that users of the library don't get additional dependencies forced on them.

If the intent is for them to be the canonical / "official" command-line interfaces then if may make sense to provide a more polished experience, e.g. using a more full-fledged framework for CLIs (e.g. https://github.com/spf13/cobra or https://github.com/urfave/cli which are commonly used). Those can provide more functionality, such as automatic generation of tab-completion and documentation / man-pages, but also come with a fair share of additional dependencies, so in that case it could be worth creating a separate module for the binaries to have a clear separation between the "library" module(s) and command-line / binary modules.

[zeroshade]

You're definitely correct that these are intended to be for debugging purposes and not necessarily expected to have full polished experiences. I personally find cobra and cli to be a bit heavy for small CLI utilities. That said, you have a good point and it's probably fine to use the stdlib here for now.

[thaJeztah]

Yes, agreed as well! We chose for Cobra many Years ago, and it served us well, but it has gained feature bloat in many areas, which in itself isn't unreasonable, but the architecture is showing its age, and likely could benefit from a more substantial rewrite.

For our projects, it's deeply ingrained in many areas and some features are valuable enough to make it a reasonable trade-off, but there's definitely some parts we'd love to have improved (which isn't realistically possible without breaking backward compatibility so ... would need a "v2").

For this repository, I tried to make my best judgment, and thought the slight rewrite was an ok trade-off.

Never hesitate to push back on my changes though! I'm just a passersby and won't have to do the maintenance (which is the actual work! ❤️)