ProcessHandleImpl should assert privilege when modifying reaper thread

Changes in JDK 19 result in modifying the process reaper thread
properties, namely `setDaemon` and `setName` without asserting
privileges, which can (depending on your security manager
implementation) result in checking the callers permissions, and its
callers permissions, etc, all the way to the thread's inherited access
control context - which is effectively empty for these threads, since
the repeater threads are innocuous. These operations should be invoked
within doPriv blocks.

Specifically, this is only an issue when running with a security manager
implementation that is more restrictive than that of the default
security manager implementation of checkAccess(Thread).

This issue has been filed to track an issue raised on core-libs-dev:
  https://mail.openjdk.org/pipermail/core-libs-dev/2022-November/thread.html#97035