Fix overcompilation due to unstable context bound desugaring

[smarter]

Context bounds are desugared into term parameters evidence$N and before this
commit, the N was chosen to be unique in the current compilation unit. This
isn't great because it means that adding a new definition with a context bound
in the middle of a file would change the desugaring of subsequent definitions
in the same file.

Even worse, when using incremental compilation we could end up with the same
context bound desugared with a different value of N on different compilation
runs because the order in which a compilation unit is traversed during Typer is
not fixed but depends on the how the units that are jointly compiled depend on
each other (as demonstrated by the stable-ctx-bounds test). This issue
affects all fresh names generated during Typer, but it is especially
problematic for context bounds because they're part of the API and renaming
a method parameter forces the recompilation of all files calling that method.

To fix this, we now only require context bounds parameters to have unique names
among all the parameters of the method. This matches how we already desugar
def foo(using A, B) into def foo(using x$1: A, x$2: B) regardless of the
context.

Note that fresh names used in other situations are still problematic for
deterministic compilation. Most of the time they're not part of the API checked
by Zinc, but they can still lead to overcompilation if they appear in an
inline def since the entire body of the inline def constitutes its API. In
the future, we should follow Scala 2's lead and only require names to be fresh
at the method level: scala/scala#6300 (The Scala 2
logic is slightly more complex to handle macros, but I don't think that applies
to Scala 3 macros), see #7661.

Fixes #18080.

[bishabosha]

may be worth noting here the predicted order of typer visiting definitions in run 1 vs run 2, to illustrate how before the change it actually had unstable names between runs.

[mkurz]

This change is causing compatibility issues when running a Play project with Scala 3.3.1 with Play artifacts build with Scala 3.3.2:

• Scala 3.3.2: class file ... is broken, reading aborted with class java.util.NoSuchElementException contextual$ playframework/playframework#12418

@smarter Can you take a look?