re-resolving indirect call to non-entrant nmethod can crash

In SharedRuntime::reresolve_call_site, it is possible for an indirect (i.e. vtable dispatch) call site to be incorrectly decoded as a direct call site on x86 as the decoding blindly inspects the 5th byte prior to the return address. If it is 0xE8 (i.e. opcode of a direct call on x86), then it is determined to be a direct call. However, it could be that there is a 2- or 3-byte indirect call instruction preceded by some other instruction that happens to have 0xE8 at the relevant position. Apparently C1 and C2 never emit such sequences but we're seeing that in rare situations, Graal does. This results in the following crash:

# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (nativeInst_x86.cpp:290), pid=19, tid=0x00007f410b0f4700
# guarantee(is_aligned, "destination must be aligned");

This can be avoided by making reresolve_call_site double check that there is a reloc info of type relocInfo::static_call_type, relocInfo::virtual_call_type or relocInfo::opt_virtual_call_type at the decoded call address. If there's no reloc info, it must be an indirect call and thus call patching is not done.