[CI] Temporarily increase pip verbosity during CI runs

[njsmith]

Attempting to debug gh-508

[njsmith]

I've visually confirmed that this is successfully causing pip to dump lots of debug output on the MacOS builders (and probably travis too, but I don't care about that).

[codecov]

Codecov Report

Merging #509 into master will increase coverage by <.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #509      +/-   ##
==========================================
+ Coverage   99.27%   99.28%   +<.01%     
==========================================
  Files          89       89              
  Lines       10432    10432              
  Branches      722      722              
==========================================
+ Hits        10356    10357       +1     
  Misses         58       58              
+ Partials       18       17       -1

Impacted Files	Coverage Δ
trio/tests/test_highlevel_open_tcp_listeners.py	100% <0%> (+0.7%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update bcc639b...32e4c22. Read the comment docs.

[Fuyukai]

I like how codecov decided this increased coverage on a file that wasn't even touched.

[njsmith]

Yes, it's always nice when you make a PR to track down flaky CI, and it encounters a different flaky CI issue... the issue codecov is complaining about is very strange. Apparently in our measure_backlog function, we have

    finally:
        for client_stream in client_streams:
            await client_stream.aclose()

and the for line got marked as partially covered in some run. The way coverage.py does partial coverage reporting, I think it wants to see at least one iteration where we execute the loop body, and at least one iteration where the iterator is exhausted and the loop exits. (As opposed to e.g. being broken out of by a break or return or exception.) But in this case, the line in the loop body actually is marked as covered in that run, and I can't see how this loop would be exited early (aclose shouldn't be raising an error here!), so ... wtf.

Oh well, I guess we can worry about it if it comes up again. Going to merge this for now because it's trivial and boring and we want it in before someone hits the flaky macos build again.