Document that params and data can be list of tuples everywhere

Fix a few inconsistencies in the doc found while working on [MechanicalSoup](https://github.com/MechanicalSoup/MechanicalSoup/pull/219).

# [Codecov](https://codecov.io/gh/requests/requests/pull/4739?src=pr&el=h1) Report
> Merging [#4739](https://codecov.io/gh/requests/requests/pull/4739?src=pr&el=desc) into [master](https://codecov.io/gh/requests/requests/commit/f6e13ccfc4b50dc458ee374e5dba347205b9a2da?src=pr&el=desc) will **not change** coverage.
> The diff coverage is `n/a`.

[![Impacted file tree graph](https://codecov.io/gh/requests/requests/pull/4739/graphs/tree.svg?token=mZGswIiXLa&src=pr&height=150&width=650)](https://codecov.io/gh/requests/requests/pull/4739?src=pr&el=tree)

```diff
@@           Coverage Diff           @@
##           master    #4739   +/-   ##
=======================================
  Coverage   66.79%   66.79%           
=======================================
  Files          15       15           
  Lines        1563     1563           
=======================================
  Hits         1044     1044           
  Misses        519      519
```


| [Impacted Files](https://codecov.io/gh/requests/requests/pull/4739?src=pr&el=tree) | Coverage Δ | |
|---|---|---|
| [requests/models.py](https://codecov.io/gh/requests/requests/pull/4739/diff?src=pr&el=tree#diff-cmVxdWVzdHMvbW9kZWxzLnB5) | `77.57% <ø> (ø)` | :arrow_up: |
| [requests/api.py](https://codecov.io/gh/requests/requests/pull/4739/diff?src=pr&el=tree#diff-cmVxdWVzdHMvYXBpLnB5) | `36.36% <ø> (ø)` | :arrow_up: |
| [requests/sessions.py](https://codecov.io/gh/requests/requests/pull/4739/diff?src=pr&el=tree#diff-cmVxdWVzdHMvc2Vzc2lvbnMucHk=) | `76.27% <ø> (ø)` | :arrow_up: |

------

[Continue to review full report at Codecov](https://codecov.io/gh/requests/requests/pull/4739?src=pr&el=continue).
> **Legend** - [Click here to learn more](https://docs.codecov.io/docs/codecov-delta)
> `Δ = absolute <relative> (impact)`, `ø = not affected`, `? = missing data`
> Powered by [Codecov](https://codecov.io/gh/requests/requests/pull/4739?src=pr&el=footer). Last update [f6e13cc...c008bf3](https://codecov.io/gh/requests/requests/pull/4739?src=pr&el=lastupdated). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments).


> As for the others, it feels unnecessarily redundant for a smaller edge case.

I find it strange to have a parameter with exactly the same behavior in different functions and different documentations. If you want to avoid redundancy, then factoring the docs with links (stg like "Parameters to be sent in the query string for the :class:`Request`. See <link to proper doc> for details.") would be IMHO better.

In the existing doc, the string is already precise enough to discourage the user from trying to find another doc (it already documents the "dictionary" and "bytes" case). When I found the doc for [Session.request](http://docs.python-requests.org/en/master/api/#requests.Session.request), it didn't occur to me that the actual doc for the `params` parameter should be searched for elsewhere.

@moy, how about we go with the below single-line copy then for the non-`request` entries.

```(optional) Dictionary, list of tuples, or bytes to be sent in the query string for the :class:`Request`.```

I'm fine with the single line, but I'm not sure everyone would understand. I would add a link to the doc of requests.request for details.

@moy, these are thin wrappers around a single call which is for a well documented function. If users have a use case where they need tuples, we have documentation around this. If they're only looking at the code, it's a single click in most IDEs to determine its usage.

The main thing we're trying to avoid here in unnecessary bloat and having several places that need to be updated for the same information. As I said above, I'm happy to make this information clearer, but would prefer we do it without establishing a pattern of copy-pasting to every function any time we make a tweak.

> If they're only looking at the code, it's a single click in most IDEs to determine its usage.

I did have to dig into the code to find this, yes. But to me, the point of autogenerated documentation (http://docs.python-requests.org/en/master/api/) is precisely to avoid asking the user to read the code. Why do you publish this autogenerated documentation online if the recommended way to read it is within the code with an IDE?

> would prefer we do it without establishing a pattern of copy-pasting to every function any time we make a tweak.

That's precisely why I suggest a link: to avoid duplicating, and to let the user find the centralized place more easily.

> That's precisely why I suggest a link: to avoid duplicating, and to let the user find the centralized place more easily.

I think we may be going in circles now. I believe we agreed on your initial suggestion to linking to the `:class:Request` (with minor wording tweaks). In your current commits, this has the same effective copy as `requests.request`. Adding two links that provide the same information, and have the potential to drift, isn't ideal.


To summarize the steps I'm proposing:
* The `params` string in `requests.request` should be consistent with the `data` string.
* The `Request` class docstring references the list of tuples. Ideally something like:
```
     :param data: the body to attach to the request. If a dictionary or list of
         tuples ``[(key, value)]`` is provided, form-encoding will take place.
     [...]
     :param params: Dictionary, list of tuples, or bytes to be sent in the query string for
         the :class:`Request`.
```
* Everything else:
```
:param params: (optional) Dictionary, list of tuples, or bytes to be sent in the query string for the :class:`Request`.
:param data: (optional) Dictionary, list of tuples, bytes, or file-like object to send in the body of the :class:`Request`.
```

OK, I read you too quickly.

I pushed essentially what you're proposing. I just kept a bit more details in Request's `:param params:`.

Weird, my local version was correct, but apparently I pushed a version with incorrect cut-and-paste. #4910 should fix this.