Improve docs on client/request configuration merging

[florimondmanca]

Fixes #1004

Update the Merging configuration docs to resolve these items:

• Document what happens when mergeable configuration (headers, params, cookies) is passed None at the request level. Improve example snippet by using X-Client-Header and X-Request-Header example headers.

• Document the gotcha that request-level auth=None doesn't disable auth, even though request-level auth is advertised as generally taking precedence over client-level auth.

[lovelydinosaur]

An alternative here would be to do the UNSET dance on each of these parameters, so that they do have the expected behaviour when passing params=None, headers=None, auth=None, allowing them to override the client default.

Would that make sense?

[florimondmanca]

Well, hmm, I don't know. We already provide the "build a request and edit its headers/params/cookies to remove items" solution for these cases. Plus, I don't know if the use case for "send absolutely no headers/params/cookies on this request" is that convincing. On the contrary there might a drawback which is that this change would be breaking to people that do pass None to these params. Not sure there are many situations, I'd suppose most likely in a kind of "wrapper" situation, but not sure. Another clearer drawback: AFAIK this would differ with Requests behavior.

On the other hand, the argument for auth is a bit more ambiguous, we'd agree? So we either change it - #1115, or keep it simple and consistent while documenting the gotcha - this PR.

[lovelydinosaur]

So, I think I'm in favour of #1115 for auth, right? It's come up as an issue for us, and it's come up as an issue for requests, plus I can fairly easily see the use cases for it.

But yes, otherwise I guess we can be okay with None meaning "use the client value" for params, headers, and cookies.

[florimondmanca]

Yup, that's my sentiment as well. Will reopen #1115.