Currently AOT compiled code generation uses the same mechanism for Java calls as normal nmethod generation: use `_resolve_*_call_blob` blobs as the destination for calls by default.

These blobs are calling into VM's runtime to find existing compiled code for called Java methods and patch destination addresses. Or use C2I adapter address to call into Interpreter if a compiled code doesn't exist.

Performance profiling shows that such call resolution process takes some time during startup when AOT code is used.

We should investigate possibility to pre-resolve these calls destination addresses if AOT code exists for called methods and can be statically bound to call site.

I think it can be done for "static" and "optimized virtual" Java calls when we know that only one target method is present.

This is applied for both: pre-load AOT code (executed on first call and have class init barriers) and normal AOT code (when all dependent classes are loaded).