Packer: Feature Request: Pretty Print Build Duration (aka Time)

My builds have gotten longer, and I've run out "low hanging fruit" optimizations. But the need for speed persists, and as a result I'm trying to get more scientific about tracking build durations for the various distros on the various hypervisors/CPU types I currently target.

With a lot of effort, I can extract duration info using the debug log (or the spiffy new -timestamp-ui option) but thought it would be nice, and helpful to all, if packer simply printed how long it takes to build a particular configuration along with the "all finished" message. It's hard for me to track start/stop times when I build a bunch of machines 1 or 2 at a time. Which why I'm asking that:

Build 'generic-rhel8-vmware' finished.

Become:

Build 'generic-gentoo-vmware' finished in 1 day 3 hours 24 minutes 25 seconds.

A superfluous improvement might would printing the duration on a preceding line in ISO 8601 format when the -machine-readable flag is used, like so:

==> generic-gentoo-vmware: P1DT3H24M25S
Build 'generic-gentoo-vmware' finished in 1 day 3 hours 24 minutes 25 seconds.

In my world, errors, and cancelled builds would also print a duration like so:

Build 'generic-openbsd6-vmware' errored: Build was cancelled after 2 minutes 2 seconds.

For extra credit, the ISO download (and possibly the vagrant-cloud/docker-push post processors could alos print out durations in the same format (pretty/machine readable), upon completion. That would make it easier for number munchers like myself to track those network intensive steps separately.

In theory all of the major 'steps' or 'stages' could print durations.. but from my point of view, it's the network heavy preparation, and publish/deploy stages, that are statistically the most significant, and thus worth tracking separately. (In theory individual provisioner/post processors could print durations using generic logic, but that would be noisy, so if we go down this road, perhaps have each "stage" print it's duration, ie download complete/vm setup (aka prep stage) -> build complete (aka provisioning step) -> post processor completion.

For completeness I'll request this feature print other statistics, like CPU time, disk IO, and network transfer; but I realize those values will be harder for packer to track/report across host platforms/providers/plugins.,, so you should only consider additional statistics if your vying for the title of "teacher's pet."

@azr if you make the change discussed in #7132, I think, it would probably be easy to add duration tracking at the same time (not sure though). I say that because in theory, a stopwatch could start when a build begins (not when packer begins).. and record stop points when control passes between plugins. And as I under your plan for #7132 it would involve adding code that is run when control is passed between plugins..

It's probably obvious, but worth noting that the start duration tracking for -parallel=true would begin at the same time for all of the build configurations, while -parallel=false would cause the stopwatch to start when a particular build actually begins, which is what I have trouble separating.

P.S. I've already started using packer builds as an internal benchmark of sorts, whenever I get new hardware online, but my numbers are crude. With this feature I could track duration over time, and if anybody is interested, I could eventually write up a summary of what I find, for all to read.