A (fully) failing test for 304 handling

This tests those resources which might can return a 304 to confirm
that the response includes all those headers which httpbis says
it must (or should):

   http://tools.ietf.org/html/draft-ietf-httpbis-p4-conditional-22#section-4.1

In our case these headers are listed in RELEVANT_HEADERS in the
test file. We don't include content-location because we aren't
using that at the moment.

This if part of issue #77

This fails at the moment, as expected. Now to make the code
align with the tests.

/cc @pads @fnd
Make the tests for 304 handling pass

This is a first draft and could do with some review from
@FND and/or @pads.

The main changes here are:

* HTTP304 temporarily subclassed to allow a header-passing
  interface when creating the exception, so that all the
  headers that we want can be sent.
* Adjustments in to signature and callers of check_incoming_etag
  and check_last_modified so that they do the right thing. Basically
  we are passing header information down the stack and allowing for
  some reasonable defaults.

As constructed these things are backwards compatible with existing
callers.

Questions:

* Does the backwards compatibility stuff impose too much noise into
  the system? Is there a different way?
* Are the defaults okay?
* Is kwargs in an exception signature okay or should we be explicit?
* Is the subclass kosher for being merged back into httpexceptor?

Also needed to change the no-transform middleware so it
engages on 304, not just 200, otherwise the cache-control header
will not match.
Fix variable declaration problem

This would only shows up when cache max age is not an int.
rename tiddlers_etag to this_tiddlers_etag

Not much better, but at least somewhat better.

This is a common problem throughout the code, the word
tiddler is _everywhere_. We, however, do not want to
get all hungarian on the code.
Take all valid headers as keyword inputs to 304

This is just an experiment to get some feedback on
how it feels. This version remains backwards compatible and
specifically constrains itself to what the httpbis spec says
is valid.
Move HTTP304 class back into httpexceptor

Change dependency vector.
Merge branch 'master' into httpbis-304
Update depencency for httpexceptor to the real version

The latest was released as 1.2.0 (which makes good sense
given the nature of the change).