want PHD `lshw_lifecycle_test` to, uh, actually involve `lshw(1)` in some way

as seen in https://github.com/oxidecomputer/propolis/pull/1032#issuecomment-3856368461 and #1035, it turns out that when the guest image is Alpine, this test does the following:

localhost:~# stty -F `tty` cols 9999
localhost:~# sudo lspci -vvx
-ash: sudo: not found
localhost:~# sudo lshw -notime
-ash: sudo: not found

which is uh, not great.

the assertion that lshw returns the same output after stopping the VM and then starting it again does (trivially) pass, which is good except for the fact that it prevented us from noticing that this test was not actually testing anything. if the guest's devices were to have been totally scrambled between the stop and the subsequent start, sudo lspci -vvx and sudo lshw -notime would nonetheless still output -ash: sudo: not found.

since we are logging in as root anyway, i am pretty sure we can just remove the sudo and it will be fine. i am not sure OTTOMH whether we login as root on non-Alpine guests, if one were to run the PHD tests against a different Linux image, but that also doesn't really happen so whatever.

Locate the PHD lshw_lifecycle_test and inspect how it logs into the Alpine guest and runs lspci and lshw. Run the test with the Alpine image, then verify that the commands execute successfully and that the lshw output comparison still covers the stop-and-start lifecycle.