[GR-51002] Improve intrinsification of method handles.

[graalvmbot]

This PR solves the orders-of-magnitude performance difference for equals/hashCode methods of records. I plan to merge this also into the GraalVM 24.0 release, and later on backport to GraalVM 23.1.

The biggest change is around the inlining policy for the special "method handle intrinsification" mode of inline-before-analysis:

• The method handles for record methods have recursive inlining. Actually pretty deep, a record with 100 fields has 100 recursive invocations of the same method. So there cannot be any recursive inlining limits, and inlining depth itself needs to be big too.
• But that requires more careful handling when we enter/exit the special mode. I enter now only when the method handle is in the root method, and removed the blanket "keep inlining most things from the java.lang.invoke package". The special mode is only entered for @LambdaForm.Compiled annotated methods, and remains only active for @LambdaForm.Compiled and @ForceInline annotated methods (with a few exception). That seems to work surprisingly well.
• A new "total number of inlinings" counter provides a bailout to prevent excessive inlining. The threshold is pretty high and should not trigger for any real intrinsifications, but it is still low enough to prevent impact on image build time.

Other notable changes:

• The profiling of guard-with-test method handles is disabled using a system property in the image generator, like Codrut already did for other kinds of self-optimizing method handles.
• To guarantee full intrinsification of VarHandle, we need to constant-fold MethodHandle.asType when all arguments are constants. That needed some relaxing of checks in ReflectionPlugins, allowed parameter types are all subtypes of our manually listed types.
• A few bugfixes for the shadow heap work are included too, because I had gate failures during various implementation stages of this PR.

For images with JIT compilation, we still use the old method handle intrinsification. Still, I think the new one is now also more correct, with the annotation-based distinction we can also reliably start the method handle intrinsification when trivial inlining is done as part of inline-before-analysis. But I did not experiment at all enabling the mode for images with JIT compilation.