Responsive logging

[juj]

Mostly Windows-specific things:

• Make the Windows Python Popen workaround disabled by default. Fortunately it does not seem to be needed when emscripten is invoked from the command line via the emcc.bat scripts. Keeping it around behind an .emscripten param/env var EM_POPEN_WORKAROUND in case it is still needed.
• Unify logging in emscripten.py behind a single function to force flush all logging immediately to console. On Windows, building large codebases would look like they hang, since the above Popen workaround and delayed logging made the build output appear only after the externally spawned processes finish.
• Add machinery to external process spawns and waits with EM_BUILD_VERBOSE >= 3 to be able to debug where the build hangs, if it hangs.

[kripken]

I worry that flush all the time can be slower on other OSes - perhaps we should only do that if WINDOWS?

[kripken]

We should likely be using logging.debug here, like elsewhere. Or is there something special in emscripten.py where logging is more of an issue? It should not generate that much actually, the bulk of the logging in most cases is from the processes it spawns (the JS compiler itself).

[juj]

Ok, I'll make the flush Windows-only. Can you elaborate on the second point, what do you refer to there? it seems that the comment is not annotated on a specific source line. Do you mean that the implementation of logmsg should do logging.debug() instead of print >> sys.stderr? Or that only the jsrun.py process tracking should do logging.debug() instead of logmsg?

[kripken]

I meant that we should use logging.* consistently in all places, unless there is a reason to do otherwise.

[juj]

Ok, I updated this pull request to use logging.* instead of logmsg(). Fortunately logging prints out messages unbuffered, which print didn't seem to do, so the flush doesn't seem even necessary!