JIT: revise how we track if nodes have been morphed

[AndyAyersMS]

Allow remorphing. Require that all nodes be morphed. Ensure that no node is morphed more than a handful of times.

Fixes #6218, #56962, #107542

[AndyAyersMS]

Based on #110658 (comment)

There are two main concerns with morph:

1. Every node should be morphed at least once, both because of required changes morph will make and because we are in the middle of propagating assertions. We were not morphing quite a few nodes created in post-order, though they mostly fall into two camps: (a) trivial leaf or near-leaf cases where there is nothing for morph to do (either any opportunity for assertion prop already happened or is not applicable); or (b) assignments to newly introduced temps that will have no "remote" uses (so we miss out on assertion gen/kill, but again, largely to no effect, as there are no redefs and all uses are local and can't be optimized).
2. We should try avoiding morphing nodes repeatedly. Also tricky to avoid in post-order, possibly (but unlikely) wrong, and in general is just inefficient.

With this change we enforce that all nodes must be "morphed" though this is weaker than ensuring that all nodes have done the proper amount of morphing. Also we attempt to count how many times each node goes though the fully general morphing process and assert if this happens too often (we may be missing cases where an "enlightened" re-morph bypasses the upper levels of morphs' general dispatch).

There is a possible opportunity for assertion gen/kill for return value canonicalization; I have left that for a follow-up PR. I do not think adding assertion gen/kill for the other post-order assignments will yield any interesting diffs but we might want to insist on it anyways.

The unbox transformation introduces new temp assignments in a remote tree, which morph's assertion prop is unable to model. This is fairly stylized and "works" since the box creation must dominate the box use, and there are no other uses of the introduced temps.

No diffs, no impact in release.

With this change the main burden going forward is on new/modified postorder expansions (and the utility methods involved), generally marking things as morphed where needed, or (rarely) allowing a full remorph.

@jakobbotsch PTAL
cc @dotnet/jit-contrib

[jakobbotsch]

Seems like an improvement on the current state of things, but I think it would be ideal in the long term if we could ensure all nodes are morphed exactly once, and go back to an even stricter version of the checking we had before. Clearly that requires some non-trivial refactoring of morph, though, although seems like it is long overdue at this point.

[AndyAyersMS]

Likely will need some ABI or ISA specific fixes here and there.

[AndyAyersMS]

/azp run runtime-coreclr jitstress

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[AndyAyersMS]

/azp run runtime-coreclr jitstress

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).