Fix for resolving accept header

[freaz]

Description

Do not set accept header when defined in HTTP request headers. I wanted to normalize headers and work with them, but that could lead to unexpected behavior and better will be to allow set as many headers and in any case. It will delegate need to normalize to client and server.

One thing I am not happy about, is how the logic is split in map-interpreter and filters.

Motivation and Context

Fixes #264

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• I have updated the documentation accordingly. If you are changing code related to user secrets you need to really make sure that security documentation is correct.
• I have read the CONTRIBUTING document.
• I haven't repeated the code. (DRY)
• I have added tests to cover my changes.
• All new and existing tests passed.

[TheEdward162]

I think the split is fine architecturally because the part in map-interpreter is responsible for collecting the information from the map (which just happens to be in a format that is the same as the header value), while the filtering is something that is specific to the HTTP client itself?

[freaz]

I don't think it is entirely wrong, but I would just like to see headers resolution in map-interpreter instead of filters.

But more importantly, when I looked at PR without focus on Accept header, I realized we work with case-sensitive keys for header names, and use of content-type and Content-Type can lead to interesting bugs.

[freaz]

I would merge this one, and apply similar approach for content-type and user-agent in headersFilter.