Improve places where CS1661 is reported

[Rekkonnect]

Inspired while working on #69273

CS1661 (ERR_CantConvAnonMethParams) currently overshadows the real diagnostics emitted for lambda parameter mismatches. It is always being reported in cases of parameter type or ref-kindness mismatches, alongside the other useful diagnostics accurately showing what the error is and being reported on the location of intertest, not covering the entire lambda.

Consider the following examples:

Action<string, string> a = (string a, int b) => { };
//                         ~~~~~~~~~~~~~~~~~~~~~~~~
// CS1661 -- Cannot convert lambda expression to type 'Action<string, string>' because the
//           parameter types do not match the delegate parameter types

//                                        ~
// CS1678 -- Parameter 2 is declared as type 'int' but should be 'string'



Action<string, string> b = (string a, string b) => { return a; };
//                                                   ~~~~~~
// CS8030 -- Anonymous function converted to a void returning delegate cannot return a value



Func<string, string> c = (string b) => { return b.Length; };
//                                              ~~~~~~~~
// CS0029 -- Cannot implicitly convert type 'int' to 'string'

//                                              ~~~~~~~~
// CS1662 -- Cannot convert lambda expression to intended delegate type because some of the
//           return types in the block are not implicitly convertible to the delegate return type

CS1661 completely overshadows the real problem by spanning across the entire lambda expression, which offers very little diagnostic value to the user.

CS1662 is similarly overlapping with an existing CS0029 but at least it does not overshadow the real diagnostic, nor is it emitted on the entire lambda.

In this case where we have a mismatch of the type or the ref-kindness of the parameter, CS1661 is best not reported as the other errors take care of this.

It should be noted that the diagnostic is not emitted when the parameter counts do not match. The only scenario that we report CS1661 altogether is a generic wrapping, while also handling the parameter type/ref-kind mismatches.

I propose that we only report CS1661 when there is nothing else that can be reported. If we can report a diagnostic about the mismatch of the type or the ref-kindness of each individual parameter, CS1661 should never appear.

[CyrusNajmabadi]

A simple fix would be to make the lambda error get reported on the =>. Then tehre's no concern about losing information. It just becomes a matter of the diagnostics not colliding with each other.