BUG/ENH: compression for google cloud storage in to_csv
- [x] closes #35677, closes #26124, and closes #32392
- [x] tests added / passed
- [x] passes `black pandas`
- [x] passes `git diff upstream/master -u -- "*.py" | flake8 --diff`
- [x] whatsnew entry

By inferring the compression before converting the path to a file object `df.to_csv("gs://mybucket/test2.csv.gz", compression="infer", mode="wb")` works. By wrapping fsspec file-objects in a `TextIOWrapper` `df.to_csv("gs://mybucket/test2.csv", mode="wb")` works as well. Path-like objects that are internally converted to file-like objects (in `get_filepath_or_buffer`) are now always opened in binary mode (unless text mode is explicitly requested) and the potentially changed mode is returned (no need to specify `mode="wb"` for google cloud files). As long as the google file is opened in binary mode (which is now always the case), we also honor the requested `encoding`.

This PR also fixes Zip compression for file objects not having a name.
it seems that only the windows py37 machine on azure actually tests the google cloud interface?!

EDIT: and one linux machine on travis Hello @twoertwein! Thanks for updating this PR. We checked the lines you've touched for [PEP 8](https://www.python.org/dev/peps/pep-0008) issues, and found:







































There are currently no PEP 8 issues detected in this Pull Request. Cheers! :beers: 

##### Comment last updated at 2020-08-31 23:19:00 UTC thanks for your review @jreback! I was lazy and used tuple unpacking to keep the diff small. I will use the named tuple explicitly in the next commits.

The return types of `getfilepath_or_buffer` were previously not checked (return types were only mentioned in the doc string - and were partly inconsistent with the input arguments). I will double check the types and add asserts instead of ignore comments. thanks @twoertwein yeah i really like the named tuple for its readability

(you could actually use a DataClass) but not sure if that adds anything Typing of `filepath_or_buffer` is a mess. I also added `IOBase` to `FilePathOrBuffer` (`io.BytesIO` and `io.StringIO` do not seem to be covered by `isinstance(..., typing.IO)`).

I ended up using a dataclass for IOargs, `NamedTuple` does not support `TypeVar`s in it. I use `TypeVar`s for encoding (stays  None/str) and mode (stays None/str or it changes from None to str).

If IOargs was retrieved inside an if-branch, I 'unpack'  it (using the tuppe names)  into the previous variables, otherwise I use `ioargs.` instead of the previous variable names. @WillAyd @TomAugspurger @simonjayhawkins if any comments; also using Generic protocols now so if you guys can review types (not to get bogged down of course.....)