want mechanism to enable paravirt clock safely

Propolis offers a Hyper-V-compatible paravirtualized clock enlightenment. We'd like to enable this for guests that know how to use it so that they don't conclude that the TSC is unreliable and fall back to emulated hardware timers, which are much more expensive to access.

While Propolis tries to follow the Hyper-V TLFS, it and bhyve are obviously not exactly Hyper-V, and we've seen in practice that some guests (e.g. some flavors of FreeBSD, illumos distributions) panic when Hyper-V emulation is enabled. (This is not a problem with the TSC enlightenment as such, as far as I'm aware; the issue is more that some guests read the hypervisor CPUID leaves, see a Hyper-V identifier, and assume that the hypervisor has other properties that Propolis/bhyve happen not to have.)

We need a way to enable this kind of virtualization feature broadly while giving users the opportunity to opt specific instances out if it happens to break them.

Related work:

• https://github.com/oxidecomputer/propolis/issues/328 - Propolis ticket tracking the paravirt clock enlightenment work
• #7783 - initial attempt to enable the enlightment globally
• #7868 - rollback of 7783
• RFD 561 discusses possible approaches that would allow users to configure virtualization features as desired here

Next steps are to close out on a design in RFD 561 and then implement whatever design is chosen.

Start with RFD 561 to understand the proposed configuration approaches, then review related issues #7783 and #7868 and the Propolis tracking issue #328. Done means closing on a design in RFD 561 and implementing the selected mechanism so the paravirtualized clock can be broadly enabled while specific instances can opt out.