Eliminate VM_isClassLibraryClass messages for JITServer

[mpirvu]

After work to improve constant field folding, the number of VM_isClassLibraryClass messages increased a lot affecting the CPU overhead of the client.
This commit reimplements the TR_J9ServerVM::isClassLibraryClass() frontend query taking advantage of the caches maintained by JITServer and eliminating said messages completely.

[mpirvu]

jenkins test sanity xlinuxjit,zlinuxjit,alinux64jit jdk17

[mpirvu]

@ymanton Could you please review/merge this PR? Thanks
@AlexeyKhrabrov Given your expertise on the subject, could you please review this PR as well. Thanks

[AlexeyKhrabrov]

LGTM, but I have a question/suggestion for a potential future improvement.

If the defining class of a method is not cached at the server, getClassFromMethodBlock() sends a client request that only returns the RAMClass address, and doesn't cache the class:

openj9/runtime/compiler/env/VMJ9Server.cpp

Lines 1677 to 1679 in 1208a4a

	JITServer::ServerStream *stream = _compInfoPT->getMethodBeingCompiled()->_stream;
	stream->write(JITServer::MessageType::VM_getClassFromMethodBlock, method);
	return std::get<0>(stream->read<TR_OpaqueClassBlock *>());

This results in two client requests instead of one for classes that are not cached at this point. I'm wondering if this happens frequently enough to warrant including the class info with the VM_getClassFromMethodBlock client response.

[mpirvu]

I looked at the message stats and for AcmeAirEE8 there are 10-20 VM_getClassFromMethodBlock messages out of 200,000

[ymanton]

LGTM.