Inferred Contextual params are less nameable

[som-snytt]

Fixes #24375

The original name can be recovered for messages.

[odersky]

The approach looks workable to me. The test failures seem to come from this part in Message.scala:

    override def ParamRefNameString(param: ParamRef): String =
      seen.record(super.ParamRefNameString(param), param.isInstanceOf[TypeParamRef], param)

Maybe we can try to just turn off seen.record here, i.e. drop the whole def? I am not sure more explanations of parameter names help. But one has to try it out and look at the changes.

[som-snytt]

Just a stop-gap update. I will revisit the parameter disambiguation.

Now it is aware that the written l and the inferred lcontextual$1 are not the same. Or maybe just let it ignore the difference.

def withFile[T](op: (l: caps.Capability) ?-> (f: File^{l}) => T): T =
  op(using caps.cap)(new File)

def test =
  withFile: f =>       // error with level checking, was OK under both schemes before
    val o = Service()
    o.file = f
    o.log

[odersky]

I think @Sporarum's comment on the issue makes sense.

[odersky]

Answering @Sporarum's comment on the issue :
#24375 (comment)

Maybe we should work on the toString function for ContectFunctionParamNames instead of intervening here.

[som-snytt]

The captures tests start to fail in the presence of java.lang.IO because of the constructor proxy shadowing rule.

There are other failing tests on recent JDKs because of the way lambdas are printed, etc.

[som-snytt]

Pushed the same "fix" downstack, but I haven't given any thought to what is desirable in a superscript, or whether other kinds would benefit from similar tweaking.