feat: Enhance virtual thread support

[He-Pin]

Motivation:
Enhances the current virtual thread support which can switch the virtual threads' scheduler.

Modification:
Use the method handle to change the scheduler of virtual threads.

1. when virtualization is on, the forkJoinPool will create a CarrierThread
2. and then all actors run on a virtual threads.
3. when virtualization is off, the actors run on the old PekkoForkJoinWorkerThread.

Result:
Virtualization with virtual threads supported.

We have a user case at $Work, where we are pulling data from a blocking API, With this, I think we can then decrease the Threads number.

based on #1734

[He-Pin]

behind an option

[He-Pin]

case ThreadPoolConfig is nowhere.

[pjfanning]

I think this can be written using MethodHandles. #1724 (comment)

[He-Pin]

@pjfanning I took another look at vert.x, which is using reflection too, let's move fast and ship it as this, and then in 2.0.0, we can drop Java 8 completely, I'm doing this in my free time, I don't like over-engineering.

Especially with the current problem of #1729, so It can only be tested in a separate cycle.

I will leave it as it is now, I vote for shipping it as it is in 1.2.0 and then we move to Java 11 in 2.0.x, btw, there are many reflections in the current codebase too.

[He-Pin]

@pjfanning If you are worried about the --add-opens, I can add a JPMS util for it, and then the support is out of the box.

[pjfanning]

• can we add a config to only support this if a config is set - and the config defaults to false?
• this means that the default Java 17+ user won't need to add extra add-opens but the ones who want virtual threads can enable the config but also will need to add the add-opens?

[He-Pin]

We are doing that at $Work (a trust env), but it's not a good choice for open-sourcing work, where people will have their modules opened unexpectedly.

Maybe a configuration with JPMSUtils seems fine, but that's another story that lives in another PR.

[He-Pin]

can we add a config to only support this if a config is set - and the config defaults to false?

Can't, will need a add-opens at least for MethodHandles' LookUp

this means that the default Java 17+ user won't need to add extra add-opens but the ones who want virtual threads can enable the config but also will need to add the add-opens?

No, if and only if a user turns on the virtualize = on, which is an advanced feature, I can update the document after
#1734

People should use the current virtual-thread-executor support, as I said , this PR is for advance feature.