Correct option switch used in command lines when parameter has a bare name

[Whatang]

click options can be given multiple name arguments, which will be used as both long and short switches, and as the name of a keyword argument to pass to the handler function. See https://click.palletsprojects.com/en/7.x/options/#name-your-options

When click.option is given a "bare" name (i.e. not beginning with a "-") it is used to name the keyword argument passed to the handler function, and is also used as the name attribute of the Option object created. There is no reason why this name has to match the comand-line switch. Indeed, there are good reasons why sometimes it should not match, e.g. if a switch is called --file you don't want the function argument to be called file since it will clash with the Python keyword.

click-web was incorrectly using the parameter's name attribute to calculate the switch name to pass on the command line. This would fail if the switch name and the parameter name were different. e.g. if an option was given as

@click.option("--config","-c","config_file", type=click.Path)

then the parameter value would be passed to the CLI as --config-file /path/to/file rather than the correct --config /path/to/file

This PR fixes that problem, calculating the switch name from the first element of the Option object's opts array rather than its name attribute. The change to the --an-option parameter for the command_with_option_and_argument in tests/fixtures/script/a_script.py tests that this works: it introduces a "bare" name for the parameter value. Many tests in the test suite fail with this additional parameter declaration, which is a valid click option specification. Changing the parameter name calculation in input_fields.py to use param.opts[0] instead of param.name restores the tests to passing.

[fredrik-corneliusson]

Thanks for the PR, and the detailed description!