PHD: refactor & add support Propolis server "environments"

[gjcolombo]

Rework the way PHD tests create VMs to introduce the notion of an "environment" in which a VM runs. In this model, starting a test VM requires a test to describe both the virtualized guest's configuration (CPUs, memory, disks, and so forth) and the Propolis server environment that should host it (local vs. remote machine, Propolis server version, etc.). Test VMs store their configurations and yield them on request. This allows tests to create "successors" to a test VM that have the same configuration but might run in a different environment.

Set up a basic helper for running instance lifecycle tests using the new framework. A test case supplies a VM, a list of actions (reboot the VM, start and stop it in a new Propolis, or migrate it to a new environment), and a closure that checks invariants after each action. This allows test authors to write low-boilerplate tests that check that an invariant holds after, say, migrating from an older Propolis version to a new one, or from one test machine to another. Add a "starter" test case that runs lspci and lshw in a guest and verifies that the results are consistent across a start/stop transition.

To support the notion of migrating between Propolis versions, environments specify Propolis binaries as artifacts. To maintain compatibility with the test runner's --propolis-server-cmd switch, add artifact store code to import a runner-supplied Propolis server as an artifact with a well-known name that test cases can refer to. Future changes will add additional well-known Propolis binaries like "whatever binary Buildomat says is at the head of the main Propolis branch."

Change the phd-build job to publish the Propolis server binaries it builds. This is necessary to refer to them as Buildomat artifacts in the artifact store. (This needs to exist in at least one build to enable further development of the "implicit Buildomat HEAD artifact" series of changes.)

Finally, touch up the way test cases refer to disks. Previously, tests created disk handles and passed them to the VM configuration builder. Now, tests just have to define a VM configuration and can ignore the "disk handle" abstraction if they don't use it. The tradeoff is that tests that want to work with interfaces specific to Crucible disks need to explicitly cast their disk handles to that type, but this seems like a small price to pay to make other tests more concise.

Tested with local PHD runs.

Related to #528.

[pfmooney]

Neat to see the test cases become a little more terse.

[gjcolombo]

Thanks for the review! The newest batch of changes should resolve all the outstanding comments. LMK if there's more I should tweak before landing.