Use the methods rack provides so we don't have to worry about the exact
header key.

Rack implements the Etag header manipulation methods, so we can use
those instead of ours.

* Introduce `ActionDispatch::Http::Headers#add` to add a value to
  a multivalued header.
* Move `Response#add_header` upstream: https://github.com/rack/rack/pull/957
* Match upstream `Response#have_header?` -> `#has_header?` name change.

eventually we'll remove this instance variable, but this is the first
step

we're storing the value in the headers hash, so lets just store the
value in one place.

Modules should be using the API that the abstract modules use so that we
can move these modules between implementations

We don't want to directly access the env hash

People should be free to mutate the header object, but not to set a new
header object.  That header object may be specific to the webserver, and
we need to hide it's internals.

Slightly improves performance, for example, a simple benchmark:

```ruby
require 'benchmark/ips'
require 'set'

SPECIAL_KEYS = %w[extras no-cache max-age public must-revalidate]
SPECIAL_KEYS_SET = Set.new(SPECIAL_KEYS)
directive = 'must-revalidate'

Benchmark.ips do |x|
  x.report('array') { SPECIAL_KEYS.include?(directive) }
  x.report('set') { SPECIAL_KEYS_SET.include?(directive) }
end
```

Output:

```
-------------------------------------
   array     67926 i/100ms
     set     74054 i/100ms
-------------------------------------
   array  2318423.4 (±2.8%) i/s -   11615346 in   5.014899s
     set  3387981.8 (±4.7%) i/s -   16958366 in   5.019355s
```

This fix the build http://travis-ci.org/#!/rails/rails/builds/2459981

This is a rebased version of #2520.

Conflicts:

	actionpack/test/dispatch/request_test.rb

There are several aspects to this commit, that don't well fit into broken down
commits, so they are detailed here:

 * When a user uses response.headers['Cache-Control'] = some_value, then the
   documented convention in ConditionalGet is not adhered to, in this case,
   response.cache_control is ignored due to `return if
   self[CACHE_CONTROL].present?`
 * When a middleware sets cache-control headers that would clobber, they're
   converted to symbols directly, without underscores. This would lead to bugs.
 * Items that would live in :extras if set through expires_in, are placed
   directly in the @cache_control hash, and not respected in many cases
   (somewhat adhering to the aforementioned documentation).
 * Although quite useless, any directive named 'extras' would be ignored.

The general convention applied is that expires_* take precedence, but no longer
overwrite everything and expires_* are ALWAYS applied, even if the header is
set.

I am still unhappy about the contents of this commit, and the code in general.
Ideally it should be refactored to no longer use :extras. I'd likely recommend
expanding @cache_control into a class, and giving it the power to handle the
merge in a more efficient fashion. Such a commit would be a larger change that
could have additional semantic changes for other libraries unless they utilize
expires_in in very standard ways.

Fix previous commit by allowing a proc to be given as response_body. This is deprecated and is going to be removed in future releases.

Signed-off-by: NJosé Valim <jose.valim@gmail.com>

Fix a bunch of pending tests by providing an introspection mode for the Response object that does up-front parsing of the headers to populate things like @etag