[Sema] Score non-settable overload choices higher in RValueToLValue fix

[gregomni]

With multiple overload choices, TreatRValueAsLValue used to just pick the first solution. We get better diagnostics if we pick a solution where the chosen VarDecl is settable. So make the impact of fixing non-settable overload choices higher, so we get a settable overload, if one exists.

I.e. if you conform to two protocols with same-named property, one of which is {get} and the other is {get set} and both possibilities end up with the same fix in the same location, it isn't much help to use the "it's a get-only property" choice.

Resolves #46265

Removed the previous commit and force pushed my branch before committing the new changes, and hadn't realized that makes GitHub automatically close the PR when there's (briefly) no changes. Oops. So here's a new PR.

[gregomni]

@xedin Thanks for the suggestion! Didn't realize the impact scoring on fixes existed until you said.

@swift-ci Please smoke test.

[xedin]

I think this might be too dramatic of an increase, we just need this to be slightly higher then default impact, increase it by too much and it would start competing with other solutions just like what you have in tests where count is a method and a property.

[gregomni]

Yep! I had gotten the mistaken impression that the impact was local to the specific choice location. Changed to just += 1.

[gregomni]

@swift-ci Please smoke test.

[xedin]

All of the nested conditionals could be simplified down to:

if (auto *var = dyn_cast_or_null<VarDecl>(overload->choice.getDeclOrNull())) {
   impact += !var->isSettableInSwift(DC) ? 1 : 0;
}

[gregomni]

Thanks, done!

[gregomni]

@swift-ci Please smoke test.