Add support for @deprecatedName

[hamzaremmal]

Closes #19077

[som-snytt]

I won't attempt it, then! Thanks!

[He-Pin]

Hope this be backported to scala 3.3.x too

[hamzaremmal]

Hope this be backported to scala 3.3.x too

It will be

[som-snytt]

The primary use case is the parameter name changed but you want to support the previous name. def f(@deprecatedName("b") cond: Boolean). Either name compiles, but one warns. If the annotation arg is absent, the semantics is don't use any name.

[hamzaremmal]

FYI: I've implemented this, I'm just making sure that nothing is broken before I push it

[odersky]

I had another idea (not what we discussed this afternoon). We could keep the logic as before but at this point, instead of failing, we do an addiitonal check. Say our argument is x = e. We check whether the method symbol has a deprecatedName("x") annotation on a parameter with new name y. If that's the case we change the NamedArg name to y and try again. If that succeeds with issue the deprecated name warning.

[som-snytt]

Despite my previous assertion, I attempted it. #19086 (comment)

Likely superseded by #21588

Note that it's necessary to check named args fairly eagerly for deprecation, since naming itself can be deprecated.

I'm sure I adopted some idioms from this PR after reading it, but I don't remember if it hits the snafu I encountered where paramSymss fails when overload resolution is comparing second param list of a poly method (because param names on the symbol and param types on the method type are out of sync).

The first attempt on the other PR was (IIRC) the suggestion from March, to try alternatives just before failing. (I don't recall the test failure.) Since it has to check even a good primary name for deprecation, it's easy just to collect the annotations for the current param list, and check first for the primary name and then for the alt name (since otherwise it will fail somehow anyway).