Better parameter names when using direct deconstruction in functions and methods

[NinoFloris]

module X = 
    let structTupleFunc (x, y as parameterName: struct(bool * bool)) = ()
    let tupleFunc (x, y as parameterName: (bool * bool)) = ()

    type C() =
        member _.StructTuple(x, y as parameterName: (bool * bool)) = ()
        member _.Tuple(x, y as parameterName: struct(bool * bool)) = ()

sharplab: https://sharplab.io/#v2:EYLgxg9gTgpgtADwGwBYA0AbEAzAzmgExAGoAfCABxgDsACAZQE9cAXGAWwFgAoWv2nuwgEArhhi0AGrQC8A3v3EtarKCLAsAKiIriAYiOphaACgRpajWgENctCtajX2MNlAByzmCBUs1Gk2AICAxaACpaIJCASmjZU2ieflolWhYdfUNjMwsrW3tHLzdPFx9A4NCIqIxY+JNE7iT+FkYqWgBhetkm5L4XdmAYKFoAfQA6ej91LQyYHMsbOwcnF2KvMurwyIrauXqe3v7B4fHtXTnzBfzloqGS719/FnKQrerdhJ4gA=

In all these cases parameterName is never used in the emitted signature.

There seems to be room to improve this somewhat when an as name capture is available.

I'm a bit wary to do that for the tupleFunc case as this function gets rewritten to a two argument IL method (names arg_1_0 and arg_1_1). It would be best to have no external (named arguments) dependency on internal names (the names of the deconstructed arguments). So the final arguments would then be called (argumentName_0 and argumentName_1)

In all cases care should be taken to prevent duplicates, as the compiler happily accepts a definition like:

let structTupleFunc (x, y as argumentName: struct(bool * bool)) (argumentName: bool) = ()

Meaning if we improve the compiler to push down any as name bindings to the parameter name we now have an invalid method with two identical method parameter names.

These parameters are also not named in tooltips, that would also improve as a result of doing this change.

[baronfel]

I think this can be closed now, as with #10810 we now take parameter names from SynPat.Named if it exists. I verified by manually disassembling a full built with that branch and the method signature uses the 'as blah' name if present.

[cartermp]

Closin'