Consider getting rid of the client CONVENIENCE_HEADERS handling

[jbandhauer]

The client code inherited a scheme for plucking out query headers that seem like they are intended to be in the headers.

That is done in parse_query_and_convenience_headers at
https://github.com/looker/looker-sdk-ruby/blob/master/lib/looker-sdk/client.rb#L458-L462

The specific headers it supports are:
CONVENIENCE_HEADERS = Set.new([:accept, :content_type])

It isn't clear that this is doing anyone any good. And, there have been a couple known instances of this being a pain for people.

Because Looker API designers were not precluded from using these strings as query param names, there are some endpoints in Looker that use content_type as a param. Those endpoints are thus confusingly difficult to use from the SDK.

The workaround is to explicitly declare the query parts like:

Instead of:

sdk.foo({content_type: 'bar', baz: 1})

Use:

sdk.foo({query: {content_type: 'bar', baz: 1}})

The SDK allows for explicitly saying which params are for the query part and which are intended to be headers. So, one can still do:

sdk.foo({query: {content_type: 'bar', baz: 1}, headers:{content_type: 'json'}})

Nevertheless, my proposal is to simply remove the CONVENIENCE_HEADERS stuff so that the only way to have hash members end up in the headers is to do it explicitly.

Yet another case of the 'helpful' name-specific handling getting in our way more than helping us.