Fix #1219: Prevent subprocess stdout and stderr from cluttering pip's stdout.

[cjerdonek]

This PR prevents stdout and stderr from subprocesses from polluting pip's stdout by making it go to pip's stderr instead.

This helps with various things, including:

• Fixes issues like sudo pip freeze output is corrupted by mercurial warnings reported on stderr #1219, when users are trying to parse the output of commands like pip freeze.
• The above has also affected other projects trying to parse pip output, like pipenv here: "pipenv lock --requirements" leaks output from git, making the result invalid, only the first time pipenv#3305 ("pipenv lock --requirements" leaks output from git, making the result invalid, only the first time)
• This PR also helps advance Review the usability of pip's command line API for calling from other processes #6099 (increasing the usability of pip's command-line API by making the output more parseable)
• It fixes (at least for call_subprocess()) an issue I noted here with using getEffectiveLevel() to determine the current log level.
• It fixes a few more (I believe all remaining) spinner edge cases. These fixes can be seen in the updates to test_spinner_finish()'s test expectations.

It also addresses this code comment inside call_subprocess() made in PR #3505:

pip/src/pip/_internal/utils/misc.py

Lines 687 to 693 in 8ef3283

	# The obvious thing that affects output is the show_stdout=
	# kwarg. show_stdout=True means, let the subprocess write directly to our
	# stdout. It is almost never used
	# inside pip (and should not be used in new code without a very good
	# reason); as of 2016-02-22 it is only used in a few places inside the VCS
	# wrapper code. Ideally we should get rid of it entirely, because it
	# creates a lot of complexity here for a rarely used feature.

The PR uses the comprehensive call_subprocess() tests I added as part of PR #6312 to make sure the code changes are working as desired.

[cjerdonek]

This is now ready.

[cjerdonek]

I just noticed that this PR will also address this pip-tools issue as a side-effect: jazzband/pip-tools#654

[awaisdar001]

Unfortunately, This issue is still reproducible on pip 19.1.1. Has this change is released?

[cjerdonek]

@awaisdar001 Can you provide more details? Like, what is the command invocation, and what is the stderr and stdout that you're seeing?