Fix parsing when a parameter is named help

[kdeldycke]

This PR fixes #2819 by having ou pre-configured --help parameter automatically change its internal name used to store its value, in the case of a user providing its own argument or option conflicting with ours.

Note that I arbitrarily used a convention of adding underscores _ to that internal name until no other parameter conflict with it. I'm ready to change that strategy if it is does not look good.

[davidism]

Perhaps we could just always force an internal name, like _click_default_help?

[Rowlando13]

I think that is probably best.

[kdeldycke]

Perhaps we could just always force an internal name, like _click_default_help?

Yeah why not! Need to check if there is a nasty case in which a user can create its own argument or option that get assigned this internal ID. 😈

Wait. Hold on to that PR. I might have found that this issue not only affects --help but any parameter... 🤔 Let me verify that...

[kdeldycke]

I just changed the strategy to always naming Click's own --help with the _click_default_help constant. And also make the name collision detection more generic and systematic: it now warns at the parameters fetching level. This greatly simplifies the tests and code.

The only compromise: the public to_info_dict() of --help now returns unconditionally the _click_default_help storage ID instead of help. I can restore part of my strategy of only adopting _click_default_help dynamically for --help if a colliding argument is detected.