Deprecate a parameter name that is not a Python identifier

[kdeldycke]

This PR prepares the ground for #3827, which is going to refuse parameter names that are not valid Python identifiers.

Of course, I fucked-up the same way I fucked-up 2 months ago with #3701 , when juggling between main and stable branches made me push to stable. 😫

So:

• I pushed by mistake e2bddbc
• I reverted my mistake on stable with d036881
• And this PR is what it should have been all along

Now, for the PR itself: this contain additional DeprecationWarning that detect when Parameter, Argument or Option gets a name that will be not allowed in the future 9.0.0 release. I.e. when these parameters are not Python identifier according to str.identifier.

This PR also copy the majority of tests that were originally proposed in #3827, so the behavior of the name is locked down and frozen. This will prevent tweaking or introducing regressions during the full 8.x cycle.

[davidism]

What do you think, should we also check keyword.iskeyword? Might be good to warn about it and see if anything comes up.

[kdeldycke]

What do you think, should we also check keyword.iskeyword? Might be good to warn about it and see if anything comes up.

Ah. That might be a good idea: test drive that check during a long 8.x cycle and see if it show up... If I implement this, what kind of severity should it triggers? A DeprecationWarning like non-Python-IDs ?

[davidism]

Deprecation seems fine. Like I said in the other thread, it could be more disruptive, but it also seems to match the intention of the str.isidentifier check.