JIT: try to ensure all enumerator methods are inlined for locally allocated enumerators

[AndyAyersMS]

If we can inline all the enumerator methods then we can stack allocate the enumerator.

See #111799 (comment) for one example.

• for non-empty List<T> we may fail to inline MoveNextRare as it may not get called by instrumented methods.
• for empty collections we may fail to inline get_Current as it never gets called 

[dotnet-policy-service]

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

[AndyAyersMS]

Currently escape analysis runs after inlining, so any fix here will involve inlining anticipating possible non-escape. We don't have decent dataflow capabilities that early, so figuring out if a "possibly stack allocatable" local object reaches a call is also going to be an approximate analysis.

There is some amount of GDV flagging going on we can likely leverage here. It works as follows:

• during importation, if we assign a local the value of a call returning IEnumerator<T> we flag add an entry (Call, Local) to the GDV map. (note to self: the current logic seemingly does a lot of work to resurface the class handle from the call, but it appears just above this bit of code we may have it sitting around and can just grab it from there).
• if we then inline that call, and see an allocation, we add (Allocation, Local) to the map
• during escape analysis we use the map to reserve space for pseudo locals. When we see an allocation under a GDV guard, if there is a map entry, we create the pseudo-local for conditional escape analysis for that particular GDV guarded allocation.

Ideally we'd also tag the locals that appear in the map so that during inlining, if any of those tagged locals is the this in a call, we boost inlining for that call in anticipation of helping to prove non-escape. And if we see such a local assigned to some other local, we propagate the tag as well.

This will overstate the cases we want but hopefully not too often; enumerator vars don't tend to be reused for other things (especially if compiler generated via foreach).