Erasable log lines

[timotheecour]

No description provided.

[juancarlospaco]

Please use Descriptive titles, even if WIP.

[Clyybber]

To add to @juancarlospaco comment, you don't need to include "WIP" in the title if its a draft PR anyways :)

[timotheecour]

long story short, this fixes the following:

• change the [Processing] messages into dots #14418 (comment)
  (. was not correctly handling hintCC, but it's only apparent when looking at stderr and stdout separately)

• makes hintProcessing more useful: in change the [Processing] messages into dots #14418 they got turned into . to address their high verbosity but IMO it also makes hintProcessing almost useless and might as well use --hint:processing:off instead of turning them into .;

so this PR instead turns them into erasable lines; it's tricker than it seems because of line wrapping for long lines, so the API needs to be aware of how many lines to erase, which I handle in this PR; it's actually a generally useful API so the goal is to (eventually, not in this PR) expose it

• honors --listfullpaths for hintProcessing
  I've had many use cases where I want to know which files are being compiled, so I actually need the full path

This works, at least on OSX (including with long lines that wrap in terminal), feel free to try it out (well, despite the CI failures which I need to fix), but I'm still trying to figure out the right way to expose this because some valid use cases want to view full lines (without erasing and without dots); so the trivial option is to add a flag but there's some push for slowing down introduction of new flags, hence the difficulty here.

a known caveat (which also affects . rendering prior to this PR although with less dramatic effect) is this requires any terminal output to call flushErasable (which is low cost, just sets a bool in this PR) so if user code has static: c_printf("foo\n") with CT FFI enabled, it may end up erasing that line instead;
(the case for static: echo "foo" is easy to handle correctly)

[stale]

This pull request has been automatically marked as stale because it has not had recent activity. If you think it is still a valid PR, please rebase it on the latest devel; otherwise it will be closed. Thank you for your contributions.