campaigns: add -vv to show executed commands

Created by: LawnGnome

This PR adds a new flag — -vv — to show every command that is spawned while executing a campaign. Here it is in action:

If only the implementation was that simple...

Unfortunately, printing log messages via Verbose* and Write* is a bit fraught right now in internal/output: the only safe way to do it is on the active "widget" (ie Progress, or Pending, or whatever), lest your message be overwritten the next time the widget is drawn. However, actually tracking what the current widget is not terribly easy, and that's only exacerbated when it's being handled in a callback from the service type.

The naïve solution here would be to track the current widget in Output and delegate to that widget's equivalent function for Verbose* and Write* calls, but that is also problematic, since they may recursively call Output.Write and friends. (And they do.) The architectural problem here is that Output really addresses two or three separate concerns: providing an API for external users, providing an API for internal users, and handling a lot of the quirks of outputting things to various terminal types.

I had about four attempts at splitting it up today, and just couldn't get it. It's a ball of yarn, and every time I thought I had the boundaries sketched out, I found something else that needed to cross those boundaries: how the output behaves has to depend on the terminal capabilities, and the output options, and has to be lockable at the entry point into the output package so that widgets can make atomic updates. The real fix here is probably to redesign how we get characters and control codes to the screen with something like a command list that can write to a buffer and then flush to the terminal asynchronously. (This would also fix some flicker issues we have that are more noticeable on Windows.)

So, instead, here's a much hackier approach. The progress bar widgets currently draw and leave the cursor at the bottom of the drawn content, but there's no particular reason this has to be the case. If we switch them to leave the cursor at the top of the drawn content after a draw, then a verbose log line can simply overwrite that line, and then the next widget draw will put everything back the way it should be. Those tend to be common, particularly when spinners are enabled, but it does increase flickering. (Of course, that's only if -v is enabled, and it's only really bad if -vv is enabled.)