Improve impPopCallArgs

[jakobbotsch]

Today impPopCallArgs works in the following way:

1. We first loop for the number of args to pop, popping each arg from the top of the stack
2. As part of this loop we call impNormStructVal with CHECK_SPILL_ALL, which is necessary because we are normalizing the arguments in reverse order
3. We finally insert the argument at the front of the arg list and then proceed to the next arg

When this is done, we loop through the arg list in order and walk the signature at the same time. We check that the implicit type coercions between the arg types and signature types are ok, and we insert some implicit casts and GT_PUTARG_TYPE.

This PR changes the loop to always walk the arguments on the stack in order. That means instead of popping arguments from the top of the stack and thus walking the arguments backwards, we start from the beginning. The benefit is that we can then walk the signature at the same time. Furthermore, when calling impNormStructVal we now only check interference with the stack entries that are not arguments since we now know that arguments will be normalized and kept in order.

While the fewer interference checks result in only small diffs, the main benefit of this change is that it will help the logic for an upcoming change where I want to consistently store signature types and class handles in CallArg. Having access to the signature when we create the args in the first place simplifies things.

Furthermore, I have cleaned things up a little bit by removing the possibility of sig being null. There was only one caller passing this, for a helper, and it can simply pop the arguments on its own.

[ghost]

Tagging subscribers to this area: @JulieLeeMSFT
See info in area-owners.md if you want to be subscribed.

Issue Details

---

null

Author:	jakobbotsch
Assignees:	jakobbotsch
Labels:	area-CodeGen-coreclr
Milestone:	-

[jakobbotsch]

cc @dotnet/jit-contrib

[jakobbotsch]

/azp run runtime-coreclr jitstress, runtime-coreclr libraries-jitstress

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[jakobbotsch]

Failures are #68690, #68510, #68669, #68756 and #68513

[jakobbotsch]

PTAL @AndyAyersMS