Fix 'GetRefEscape' for invocation using old rules

[RikkiGibson]

Closes #80244

The reason this only pops up when indirecting to a local is: the safe-contexts of a local are calc'd when its initializer is visited, using GetRefEscape()/GetValEscape(), and are stored. When a usage of the local is found, these safe-contexts are looked up and checked against the context of the usage.

Simple cases like return ref rs[1] don't end up actually using GetRefEscape() for ref rs[1]. Instead it uses CheckRefEscape() only, which uses a completely different code path to check the escape, which correctly understood that this does not escape by-reference.

The GetRefEscape() path needed to be changed to reflect that this doesn't escape by-reference in the old rules.

I saw that the Check() path also sometimes adjusts the MethodInvocationInfo to drop the receiver in order to visit it separately. This didn't seem necessary here.

[RikkiGibson]

A similar check occurs in line 3001, for the "new rules", where it delegates to helper GetParameterRefEscapeLevel that accounts for UnscopedRef, etc. We could consider also using that helper here. However, I feel the implementation here, is somewhat more clearly in line with the standard.

[AlekseyTs]

LGTM (commit 2)

[RikkiGibson]

Looks like CoreClr test jobs have all timed out. I checked one of the jobs and all the work items are still in Waiting state after 90 minutes. So there might be an infra issue.