[TESTBUG] gtest pseudo-JavaThreads could be more regular JavaThreads

In the review for JDK-8214097 the curious nature of the gtest JavaThread subclasses was discussed - in particular their lack of a java.lang.Thread instance which means we have to be careful not to execute certain JavaThread code - e.g. exit().

It was suggested these might be made more "normal".

One way to do this would be to emulate what is done for the "service thread":

void ServiceThread::initialize() {
  EXCEPTION_MARK;

  const char* name = "Service Thread";
  Handle string = java_lang_String::create_from_str(name, CHECK);

  // Initialize thread_oop to put it into the system threadGroup
  Handle thread_group (THREAD, Universe::system_thread_group());
  Handle thread_oop = JavaCalls::construct_new_instance(
                          SystemDictionary::Thread_klass(),
                          vmSymbols::threadgroup_string_void_signature(),
                          thread_group,
                          string,
                          CHECK);

  {
    MutexLocker mu(Threads_lock);
    ServiceThread* thread = new ServiceThread(&service_thread_entry);

    // At this point it may be possible that no osthread was created for the
    // JavaThread due to lack of memory. We would have to throw an exception
    // in that case. However, since this must work and we do not allow
    // exceptions anyway, check and abort if this fails.
    if (thread == NULL || thread->osthread() == NULL) {
      vm_exit_during_initialization("java.lang.OutOfMemoryError",
                                    os::native_thread_creation_failed_msg());
    }

    java_lang_Thread::set_thread(thread_oop(), thread);
    java_lang_Thread::set_priority(thread_oop(), NearMaxPriority);
    java_lang_Thread::set_daemon(thread_oop());
    thread->set_threadObj(thread_oop());
   _instance = thread;

    Threads::add(thread);
    Thread::start(thread);
  }

Another thing to check is that these test threads can't terminate while the creating thread may still be interacting with them. In particular os::start_thread uses the startThread_lock() of the osThread, but if the new thread terminates and deletes itself it also deletes the startThread_lock, which may still be in use by the creating thread. For normal JavaThreads this cannot happen due to synchronization in the java.lang.Thread.start() method.