This PR was submitted for the 2.0 branch but it was merged into the 2.1 branch instead (closes #8098).

Discussion
----------

[HttpKernel] Fixed two bugs in HttpCache

| Q             | A
| ------------- | ---
| Bug fix?      | yes
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #8097
| License       | MIT
| Doc PR        |

1. 304 responses always send "Content-Type: text/html; charset=UTF-8"
header
I discovered that the HttpCache::handle method calls Response::prepare
after calling Response::isModified.  Response::isModified removes the
Content-Type header as it should, but Response::handle adds in the
default Content-Type header when none is set.  If the default
Content-Type is not the correct Content-Type, then the Content-Type in
the cache gets clobered.  I solved this problem by moving the
Response::isModified call after the Response::prepare call.  I updated
the testRespondsWith304WhenIfModifiedSinceMatchesLastModified and
testRespondsWith304WhenIfNoneMatchMatchesETag tests to verify that the
Content-Type header was not being sent for 304 responses.

2. Failure to invalidate cached entities referred to by the Location
header
I discovered that the Store::invalidate method was looking for Location
and Content-Location headers to invalidate, but it was looking in the
request headers instead of the response headers.  Because the
Store::invalidate method doesn't take a response, I decided it was
better to move this logic to the HttpCache::invalidate method instead.
I updated the testInvalidatesCachedResponsesOnPost test to verify that
Location headers are getting invalidated correctly.

Commits
-------

a4251bd [HttpKernel] Fixed two bugs in HttpCache