[jdk17] RFR: 8268405: Several regressions 4-17% after CHA changes

[Vladimir Ivanov]

Recevier validation code in `Compile::optimize_inlining()` added by JDK-8267807 is way too strict. In particular, it rejects perfectly valid cases when unique concrete method comes from a superclass ( `receiver_type->klass() <: 
 cha_monomorphic_target->holder()`).  

Instead of reworking the validation logic, I decided to completely get rid of it and follow John's @rose00 suggestion [1] to perform receiver checks at runtime when needed. As I described earlier [2], receiver checks should never fail unless there's a product bug lurking in the code. Debug builds will assert if it ever happens (controlled by `-XX:+-VerifyReceiverTypes`), but product builds will deoptimize at the call site instead.

(The fix depends on #55 to avoid assertion failures in `Parse::do_field_access()`.)

Testing:
- [x] hs-tier1 - hs-tier6
- [x] manual performance runs (dacapo-jython, in particular)  

[1] https://github.com/openjdk/jdk/pull/4212#discussion_r643467030
[2] https://github.com/openjdk/jdk/pull/4212#discussion_r644377036

-------------

Commit messages:
 - Fix

Changes: https://git.openjdk.java.net/jdk17/pull/60/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=60&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268405
  Stats: 81 lines in 9 files changed: 40 ins; 28 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/60.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/60/head:pull/60

PR: https://git.openjdk.java.net/jdk17/pull/60