Handle progress / informational messages more cleanly

[Miles Bader]

The current "Progress" stuff more or less works, but is ... messy, and we don't really deal with other sorts of "informational" messages at all (they just get dumped to stdout). For instance, the "loading big image" and "adding large mesh" info output is just printed directly to stdout, often with garbled results when multithreaded.

It would be nice to have something that's less intrusive, and at the same time, handles more cases such as random messages.

Maybe instead of passing around an explicit "Progress" reference, we should just have a thread-local variable pointing to some sort of output-management object...

Another question is how to deal with multithreaded output.

The types of output that we care about are:

1. All threads used in parallel towards one task, e.g. the main rendering "progress X%" message, or photon-shooting progress when we get around to multi-threading it.
2. "Info" output, that is a single instantaneous event, but which we want presented nicely to the user, and which is valuable enough to keep around.
3. Various random "time-consuming" messages that happen on single threads, e.g. the "loading image....done" or "adding mesh" messages.

Cases (2) and (3) can happen during case (1), but not the reverse.

In general we want the multiple threads in case (1) to be presented as working towards a single goal, not as individual threads, so there should be only one "output" for multiple threads -- however this is complicated by the fact that other types of progress output can happen in individual threads at the same time (for instance, when one thread loads an image).

The output in cases (1) and (3) is only interesting while it's happening, and does not need to be preserved once the task they document is finished.

The top-level main thread info output while single-threaded is I guess a case of (2). Although it's simple to deal with single-threaded output just by writing to stdout, it might be nice to include it in this mechanism just so all output is handled identically, so we can easily use other output methods, e.g. to a GUI or whatever.

Rendering:  10%   [loading large image foo.exr..., adding large mesh...]