Require an Argument name to be a Python identifier

[kdeldycke]

This PR lockdown edge-cases and surprising behavior in the way Click transform arguments and options specifications and determine their canonical names.

It is in the same vein as my previous PR at #3808 , and is also based on a collection of edge-cases I accumulated over the years. It also covers platform differences between Windows and Unix-like (see: #2483).

This PR does not change the behavior of Click: it only add unitests and public documentation. I don't like some of the cases highlighted here, but I'll refrain from suggesting any change or refactoring. I'll leave that for future exploration and debates in 8.x or even 9.x releases.

Unless other maintainers point to some cases being obviously wrong and that needs fixes. In which case I'll be happy to address them.

[davidism]

Both of these seem like bugs. I feel like the automatic names should always be normalized and pass str.isidentifier.

[kdeldycke]

Both of these seem like bugs. I feel like the automatic names should always be normalized and pass str.isidentifier.

OK cool, that was also my feeling. We don't want special treatments of the name of parameters, whatever their kind (options or arguments). I cannot find any reasons with the transformation should be different between the two kinds. So in the end yes, str.isidentifier should be the minimal check common to the two.

[kdeldycke]

Both of these seem like bugs. I feel like the automatic names should always be normalized and pass str.isidentifier.

@davidism Done. I did not pushed the normalization too much.

So there is one bothering difference between Argument and Option: the latter makes click.option("--in-file", "Input_File") names its parameter Input_File, while Argument forces it to input_file. Should I align both? I would tend to yes.