bhyve: add command to list config options

[novel]

Summary

For a software built on top of bhyve(8) and/or managing bhyve(8),
it is very convenient to know what specific features the given binary supports.
Currently, bhyve(8) provides some of this information, and it could be
retrieved by parsing bhyve -h, bhyve -s help, bhyve -l help.

Sometimes it is not enough, for example, the recently added
"oemstrings" feature cannot be fully probed using these commands.
Over time, some workarounds were suggested. Specifically:

• Mapping features to __FreeBSD_version. I see at least two issues with that:
  • __FreeBSD_version does not directly map to bhyve(8) features, so this is simply not accurate.
  • bhyve(8) might be updated separately from the system, which is not so uncommon, especially for development purposes. Then such a probing will be inaccurate.
• Manual pages parsing. I see more disadvantages with that:
  • Manual pages are meant to be read by a human. Extracting information from it by a machine is not the most convenient thing. Especially understanding side notes like: "Note, feature 'foo' is arm64-only!".
  • Manual pages might be inaccurate, they might miss options.
  • bhyve(8) could be used in an environment where manual pages are not installed.

This commit attempts to close this gap by introducing the "bhyve -o
help" command which prints all the supported configuration variables.
In my opinion, it is, in combination with the other commands mentioned
above, sufficient to retrieve most of the capabilities of the given
bhyve(8) binary.

The current implementation defines a simple configuration schema for
common and machdep code and prints out a list of supported configuration
variables for the current architecture.

It sits a bit to the side to the rest of the code which is okay for RFC
purpose.

The next step as I see it would be extending set_config*() functions
to validate the user provided values against the schema, so users get
notified early on incorrect or misspelled configuration variables.
It would also be nice to allow users to only validate their
configuration, think of 'nginx configtest / -t'.

[chuck]

I like the approach of defining the options in each module (e.g., machdep), but it would be interesting to see what this approach looks like for one of the storage devices (e.g., NVMe) which have both their own options as well as the common blockif options.