[clr-ios] Composite-r2r with interpreter fallback leads to significant IL_STUB interpretation if FEATURE_JIT is disabled

This behavior was initially observed on ios startup with coreclr enabled by @kotlarmilos, with the overwhelming majority of interpreted methods being IL STUBS on maui sample app ((https://gist.github.com/kotlarmilos/7a6aca4dbeb871c80c3dac4785bf4af6))

In order to reproduce on desktop, I randomly selected the json benchmark (https://github.com/BrzVlad/benchmarks/tree/main/json). I built the runtime with `FEATURE_JIT` disabled and with added logs for jitted/interpreted methods (https://github.com/BrzVlad/runtime/commit/6ee645c8eda1a6b593265b092a5f1ab9fce86391). I did a self contained publish of the json project, replaced the runtime binaries and did a composite r2r compilation of the entire app (https://github.com/BrzVlad/benchmarks/blob/main/json/composite.dll.rsp).

If the runtime has jit enabled there is no interpreter compilation of IL_STUBs, but also apparently no fallback to jit either for these stubs. When jit is disabled, roughly half of the methods compiled are IL stubs. https://gist.github.com/BrzVlad/f26bf894b9b8238b830d0750223ecb9b

I'm not sure, but this might suggest that when `FEATURE_JIT` is enabled, there is an alternative cod generation mechanism for these IL_STUBS that doesn't go through the jit. If that's the case it seems the only solution for ios would be to have a r2r flag that triggers the inclusion of some of these stubs in the image ? Would these stubs be limited enough in numbers for this to be feasible ?

TODO:
- [ ] figure out actual impact in terms of startup for these IL stubs on MAUI sample. (rough estimate would be 5-10% of startup)
- [ ] avoid interpretation of pinvoke stubs
- [ ] avoid interpretation of unboxing stubs (these also show up in a couple microbenchmarks)
- [ ] investigate scenarios that require the instantiating stubs