Cli providers params

[getzze]

closes #1179

This is a breaking change, for command line usage.

[etherealite]

I like a lot of what I'm seeing here, getting rid of the click-option-group package is nice. Keeping all of the click usage confined to one module is clean.

I think I would prefer if this could be made a little bit closer to the approach that the Typer project uses. It combines using docstrings with an annotated function signature. See it in action in the CLI Options with Help section of their docs.

I would really really really prefer to not have anything syntactic in the docstrings. Using the docstring in the generated docs is great, but don't parse it.

class SomeProvider(Provider):
    def __init__(
            self,
            username: Annotated[str, Option(help="OpenSubtitles username")],
	    password: Annotated[str, Option(help="OpenSubtitles password")],
	)
        """
        Downloads subtitles from OpenSubtitles.
        
        [username] and [password] are required if not set in config.toml
        """
        ...

subliminal --help
Usage: subliminal [OPTIONS] COMMAND [ARGS]...

  Subtitles, faster than your thoughts.

Options:
  -c, --config FILE               Path to the TOML configuration file.  [default: C:\Users\etherea
                                  lite\AppData\Local\subliminal\subliminal\subliminal.toml]
...

Commands:
  cache     Cache management.
  download  Download best subtitles.

Providers:
  opensubtitles
  ---------------
  Downloads subtitles from OpenSubtitles.
        
  [username] and [password] are required if not set in config.toml

Instead, use the signature annotations for anything where you'd need to parse a docstring and inline the docstring into the generated documentation.

I think it's worth raising that hard coding the parameters that an extension can use is pretty restrictive. Who knows what kind of requirements might be needed by some future extension. Is there not some way to allow more flexibility in this regard?

Perhaps allowing aping a narrow subset of click's api and exposing that to extensions would work?

[getzze]

I like the usage of Annotated type hints, thanks, it's much better than parsing the docstring.

I think it's worth raising that hard coding the parameters that an extension can use is pretty restrictive. Who knows what kind of requirements might be needed by some future extension. Is there not some way to allow more flexibility in this regard?

It's not the case! It takes all the arguments of the __init__ method and transform them into click options. I hard-coded arguments to SKIP for the refiners but not the providers.

[etherealite]

I'll try and incorporate this and the examples you gave in #1177 into my provider soon.

[getzze]

I decided not to use Annotated type hint and parse the docstring. If needed we can do it in another PR.