hxbrief: Decide on best defaults about dropping

Nobody has claimed this yet.

stdout/stderr usage is a bit weird. Two opposing standpoints:

1) Spam logging info, progress stats etc to stderr, then provide your main output to stdout. Useful, because when writing scipts that do `MYVALUE=$(some_command)` then you don't want info logs to end up in `MYVALUE`. stderr is more of a debug/log/warning channel.

2) stderr is named after "error". If errors happen, the corresponding info will probably go to stderr, and it is important info to debug the thing. If it is some non-trivial process that ran for half an hour and then printed 5000 lines of important info the stderr, you better hope that your scrollback is long enough or you redirected the full thing to a file.

Unfortunately, for `hxbrief` these hint to opposing answers to the question "should stderr be retained". 1) suggests that we can drop it; stdout is what is important. 2) suggests that on the contrary, stderr must not be dropped, for it contains the most important bit (how something failed). One could argue that for devs, this is even more important than a program that succeeded with some trivial output.

I see the following options to this conflict of "best default":

1) Make dropping stderr the default (eww)
2) Make keeping stderr the default (also eww, because the tool loses a lot of value)
3) Hide things, but keep some/all scrollback internally, show it once the program returned with `exit code != 0`. Eww, because we already partially printed the scrollback and cannot undo that, but now retroactively want more? Could print the last 50 lines of stdout/stderr output but that is finicky
4) On `exit code != 0` switch to an interactive (fullscreen?) mode that allows inspecting the output, dumping it to a file etc. This feels like both the most annoying to implement, the least expected (from a "simple" tool) but also the most principled/safest approach (if the command ran for half an hour, that printed _something_ to stdout/stderr and failed, you probably want to not lose that error message, no matter how many lines or if it printed to the "wrong" stream..)

No files, tests, or entry points are named. Start by locating hxbrief's current stdout/stderr handling, then evaluate the four alternatives described in the issue; done means selecting and documenting a default behavior, with any implementation scope identified.

Written by the indexing model from the issue text.