Tighten up the test suite's stderr checks

[cjerdonek]

This is a relatively simple PR that does the following four things (each in a separate commit):

1. Makes deprecated_python pass allow_stderr_warning=True instead of expect_stderr=True. This narrows / tightens up the test expectation.
2. Removes the logic for an old check for an SSLContext warning, since that is now subsumed by the deprecated Python check.
3. Makes expect_stderr=True mean the weaker allow_stderr_warning=True. Similar to (1), this makes the test expectation more specific.
4. Checks for a couple more incompatible argument combinations, which is similar to the suggestion @xavfernandez made to me on PR Allow finer-grained testing of subprocess stderr. #6342.

[cjerdonek]

@xavfernandez This is now ready to be reviewed.

There are two things I think should be done in a follow-on PR:

1. Change allow_stderr_error to have the meaning of expect_stderr_error (if possible, or if not, add expect_stderr_error as another option), and
2. Change allow_stderr_warning to have the meaning of expect_stderr_warning (if possible, or if not, add expect_stderr_warning as another option).

Both of the above would make the tests more precise.

I tried doing (1) here, but I found that there are ~35-70 tests (depending on how much group 1 and 2 overlap) where expect_error is being passed seemingly unnecessarily (since no error actually occurs). Thus, it's a bigger change that I think should be done separately.

I don't know how many tests (2) would affect.

[xavfernandez]

This isn't clear: one could think that 2.7.9 is dealt with in deprecated_python but currently, only 2.7 and 3.4 are.
(and if the 2.7 warning is removed, it's unlikely someone will add a special case for 2.7.9...)
I think we can drop the comment about 2.7.9 altogether.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.