Investigate changes in handling of dynamic invocation forwarders for recognized methods

[sstrickl]

Currently, dynamic invocation forwarders (DIFs) of recognized methods also have the same recognized kind set. For example, this means that DIFs of recognized methods are replaced with the same inlined code that the original recognized method would have been if it had been used instead. This is safe if the parameters to the method are non-generic (and thus checking the concrete CIDs removes the need for the DIF checks), but may cause issues if generics are involved.

A safe approach would be to just drop the recognized kind on DIFs (i.e., d6e9e15), but that removes any chance of replacing the DIF call even when safe. Thus has unnecessarily caused performance degradation in some of our internal benchmarks that make use of type dynamic, either implicitly or explicitly, and thus that simple change has been reverted in 4969bc6.

A better approach would still be to drop the recognized kind on DIFs, but adjust code that checks for recognized methods to also check and see if we're dealing with a DIF of a recognized method (in cases where that makes sense). If so, then we could take appropriate action. For example, in the inlining case, we could check that the involved parameters are non-generic and thus the DIF type checking won't trigger in the optimized case that is being inlined, and so use of the DIF itself can be removed. (Of course, the deoptimized case would fall back to calling the DIF and thus do appropriate type checks if needed).