refactor Thread::is_JavaThread_protected

During the code review for the following RFE:

    JDK-8249004 Reduce ThreadsListHandle overhead in relation to direct handshakes

[~coleenp] mentioned that she was not happy about the
"bool checkTLHOnly" parameter that was added to
Thread::is_JavaThread_protected(). The new parameter
basically turned Thread::is_JavaThread_protected() into
two different functions with the decision on which one to
execute based on the new parameter. She would prefer
to refactor Thread::is_JavaThread_protected() into two
functions and have Thread::is_JavaThread_protected()
call the new function for the portion of the logic that was
moved.

The new calls to Thread::is_JavaThread_protected() that
passed "true" for the second parameter would change to
call the new function.