Deprecate _ syntax for type wildcards

[nicolasstucki]

Warn in: 3.4
Error in: TBD

[smarter]

I just saw that we now warn on:

trait Base[X]
trait One[X] extends Base[X]
trait Two[X] extends Base[X]

def foo(one: One[Int]) = one match
  case two: Two[_] =>
    two: Two[Int]
  case _ =>
    ()

```-- Warning: try/cond-map.scala:26:16 -------------------------------------------
26 |  case two: Two[_] =>
   |                ^
   |`_` is deprecated for wildcard arguments of types: use `?` instead
   |This construct can be rewritten automatically under -rewrite -source 3.4-migration.

I think this is misleading: in a type test, Foo[_] is sugar for Foo[t] where t is an unnamed type variable with inferred bounds, which is why two is a subtype of Two[Int].
If I replace Two[_] by Two[?] then the code still compiles because it turns out we desugar the latter like the former, so if anything we should deprecate case two: Two[?], but really I think both forms are fine and there's no need to deprecate anything.

[som-snytt]

• change the stackoverflow question from "how many uses of underscore are there in Scala?" to "how many uses of underscore did they leave us?"

[nicolasstucki]

We could generalize #18887 to all patterns.

[nicolasstucki]

I think this is misleading: in a type test, Foo[_] is sugar for Foo[t] where t is an unnamed type variable with inferred bounds, which is why two is a subtype of Two[Int].
If I replace Two[_] by Two[?] then the code still compiles because it turns out we desugar the latter like the former, so if anything we should deprecate case two: Two[?], but really I think both forms are fine and there's no need to deprecate anything.

Followup in #19249