Improve compiler error recovery for null coalesce assignment operator

[DoctorKrolic]

Redo of #74218
Related to #73894

[AlekseyTs]

Done with review pass (commit 1), tests were not looked at. It looks like the change affects scenarios that fall outside of the stated goal of this PR. I suggest making adjustments to affect only error scenarios with target typed new on the right. #Closed

[DoctorKrolic]

This PR is based on the following semantics of ??= operator:

• If left type is a reference type, the right-hand side should also be that reference type
• If left type is nullable value type, the right-hand side should be an underlying value type of that nullable type

This semantics is independent on what shape the right-hand side is. Therefore, limiting this recovery to only new() scenarios seems like an overfitting to me. If you look at tests, I heavily verified other target-typed expressions to ensure they get assigned a type since they are most likely to benifit from this change in IDE scenarios even if specific bugs where not discovered yet. But even for non-target-typed scenarios this recovery makes sense since now compiler can insert additional conversions when necessary, which are gonna be present in the success scenarios anyway. Look at ErrorRecovery_ReferenceType_ImplicitConversion and ErrorRecovery_NullableValueType_ImplicitConversion for such examples

[AlekseyTs]

If left type is nullable value type, the right-hand side should be an underlying value type of that nullable type

I do not think this is accurate. #Closed

[AlekseyTs]

Done with review pass (commit 2), tests were not looked at. Some of the previously made comments still look relevant. Also, an alternative way to suppress cascading diagnostics was suggested. #Closed

[AlekseyTs]

@DoctorKrolic It looks like PR validation is failing #Closed

[AlekseyTs]

LGTM (commit 10)

[AlekseyTs]

@dotnet/roslyn-compiler For a second review on a community PR