Retaining temporary IL slots allocated for passing rvalues as lvalues for the duration of the whole encompassing expression.

Passing rvalues to "in" parameters require allocation of temporary IL slots.

```C#
var result M1(42).ToString();

 // where  M is declared as
ref readonly int M1(in int x) {...}

// needs to be emitted as:
int temp = 42;
var result M1(ref temp) .ToString();   // passed by reference
```

This pattern bring an issue of the lifetime of such temporaries. Note that `M1` can return its argument back by reference, so the variable must exist as long as the return variable exists. - longer then the call to M1 itself.

The situation where we would have to pass an rvalue by reference via a copy was possible before, but it was very rare, so the solution was to just "leak" the temp. I.E - do not release such temps back to the temp pool. This is not a good solution when the situation becomes more common.

In this change we introduce a mechanism that collects temps of this kind and keeps them as for the duration of the most encompassing expression.
We will use the same mechanism for the preexisting cases as well.

Why "encompassing expression" is a sufficient extent for the temps. Consider the following concerns -

1) It is not possible to store a result of a `ref readonly` call, so the temp does not need to be retained at block level. - we do not allow `ref readonly` locals in source.
2) Internally compiler can create long-lived `ref readonly` temps for the purpose of returning from exception regions. This is not causing a concern since rvalues are not returnable and can never be stored insuch refs.
3) We sometimes call struct methods on a temp, there is no concern with the life time of such temps since struct `this` it cannot be ref-returned.
4) Sometimes short-term ref temps become mapped to long-term temps as a result of async spilling. We do not need to handle that specially here since those already have appropriate life times when extracted into  block variables in lowering.

Instead of mapping the pointer to a pointer temp, it was mapped to the managed pinned reference (which does not even have the same type).
At all the places where the pointer was used, the actual reference was converted to the pointer, repeatedly.

I.E.

```C#
fixed(int * p = &v)
{
    Use(p);
    Use(p);
    Use(p);
}
```
was emitted as

```C#
try
{
     pinned ref int refTemp = ref v;

    Use((int*)refTemp);      // unsafely cast pinned ref
    Use((int*)refTemp);      // unsafely cast pinned ref
    Use((int*)refTemp);      // unsafely cast pinned ref
}
finally
{
      // zero-out refTemp
}
```
instead of logical pattern matching the semantics:
```C#
try
{
     pinned ref int refTemp = ref v;
     int * p = (int*)refTemp;  // unsafely cast pinned ref

    Use(p);
    Use(p);
    Use(p);
}
finally
{
      // zero-out refTemp
}
```

The reason for the strange emit was never truly understood. In fact, in other cases, like fixed string, the more obvious variant was used.
One theory was that this codegen was just because of the lack of internal expressiveness in the old compiler around byref locals and we simply carried it forward.
The inconsistency required special casing of such `fixed` statements  in binding, lowering, codegen and in the semantical model, which must expose the "logical" shape of the statement.

Another guess was that this kind of emit was better for JIT.
That turned out to be not true. To the contrary - while a pointer temp would be very optimizable, repeated accesses to the pinned ref actually results in noticeable overhead in the JITted code, forcing users to use workarounds like:

```C#
fixed(int * p = &v)
{
    // PERF: accessing p has additional expenses, so store it in another temp;
    int * cheapP = p;
    Use(cheapP);
    Use(cheapP);
    Use(cheapP);
}
```

Users should not need to do the above. Compiler should do that in the first place.

Fixes: #18615

For IOperation purposes

Ensure that we get a well formed child IOperation tree even for bound nodes for whom IOperation support is not yet implemented

This ensures that the analyzer driver/operation walker is able to find all the descendant IOperation nodes within these not yet implemented features. We should remove the IOperationWithChildren interface once we have designed all the IOperation APIs.

TODO: Implement the VB part.

Fixes #8884

Fixes:#17756

Fixes #14882
Fixes #13840
Fixes #13915

* fill out the visitor for BoundMethodGroup

* add vb tests and yield in c# test

And other changes per code review.

Include HasValue check in BoundSwitchStatement so any display class allocation is moved outside of the check

Fixes #5395.

Adjusted Binder, Optimizer, Flow Analysis, code generator and majority of bound tree visitors to not use recursion to handle binary expressions nested on the left side of another binary expression.
Adjusted majority of bound tree visitors to detect that stack overflow is about to happen while an expression is being traversed and report a diagnostic pointing to the expression at fault instead of crashing compiler.

Fixes #4697

Stack spiller tried to save a temp and reuses spilled LHS to store the results of the whole expression.
However, the LHS is not always spilled into a temp. Readonly fields, for example, stay as they are.

As a result the optimization leads to modification of the readonly field which is not even verifiable.,

The change simply introduces a temp, which, if happens to be temp copy of a temp and thus unnecessary, is elided by the stack optimizer who is in a better position to reason about redundancy of locals.

Fixes #4628