Otherwise tests that provide data for subsequent tests that are
marked xfail for minor problems would not have their data
available.

Add support for skipping or expecting failure on a test

This is needed because during the test writing process there
are often _many_ things that ought to succeed but don't that are
beyond the scope of the immediate project. For example a framework
not properly returning a 405 when a method is not allowed, or
returning 405 but then not returning the Allow header.

This feature required switching the base test case from unittest to
testtools. The former has changed (in Python 3.4) the internals of how
expecting failure is handled and as a result making it work with
dynamically generated tests was proving extremely difficult.

An additional shell driven test is provided for coverage of
skip and fail.

It wasn't counting the number of tests and it should to say it
is just running one test.

In some APIs it is useful to refer to the response of a previous
request in the response of this current request to, for example,
verify that an ID continues to be used.

Up to now $RESPONSE handling worked in url and data, this change
adds it to response_strings and response_json_paths.

As with all of the $RESPONSE handling, this is power that should
really only be used when testing existing APIs. If you need a lot of
this when you are developing new APIs YOU ARE DOING IT WRONG.

Having coverage information will help improve future testing.

Also add some POST tests to enhance coverage of the the SimpleWsgi
test backend.

The limit tox target confirms that interception still works when
limiting the tests that will be run.

If a pattern is passed to the test runner such that only
some tests in a YAML file are to be run, the unrequested
tests are represented in the TestSuite as empty TestSuites.
These do not have a 'fixtures' attribute. This can result
in the WSGI-intercept not being discovered and installed.

Instead of asking for the first test when looking for fixtures,
we traverse the suite until we find the first test which has
it.

If a test specifies a header which is not present in the response
provide a verbose message of what headers are present.

Fixes #10.

Prompted by flake8 and pylint.

Every test needs its own name or otherwise we can't track it.

HttpTestCase can inherit from unittest not testtools.

Some WSGI applications require a lot of prior setup before they can
be use. Since we want most of that setup to happen in fixtures,
wsgi-interception is delayed until after all extant fixtures have been
started. This is done with a built in default fixture that is run as
the most deeply nested of the context managers.

The intecept callable is passed on along to the tests so that suite
can be made aware of and use it when using the intercept context
manager. If the callable is a function, when it is passed into the
class builder, it can become bound to the TestCase. This binding is
unbound in the caller.

If a fixture class raises unittest.case.SkipTest then all the tests
in the YAML file associated with that test will be skipped.

For clarity and readability.

This is starting to point out that there really ought to be unit
tests for the various modules. The gabbits confirm things end to end
but not the details.

README.rst: Nicer formatting for commands

An error meant that the name of the current test included the name
of the prior test. Each test name getting longer and longer.

To keep things moving.

This separates the loading of the data from turning that data into
tests, making things a bit more readable as well as opening the
eventual possibility of loading from other formats.

* Better jsonpath error messages

When the YAML files uses JSONpaths that do not or cannot match we
need to know which patch it was that didn't match, otherwise we just
get a rather lame error message that is not useful information for
fixing the problem.

* regexp matches for response headers

Returning the / / makes the regex stand out better.

If the expected value for a response_header is wrapped in '/'
the value is treated as a regular expression and passed to
`testtools.TestCase.assertRegexpMatches`.

Fixes #6

This is rather limited for now, as fixtures are not yet sufficiently
fleshed out to have a clear idea of how they are going to work.

It just makes more sense.

It's likely there will need some tuneups with regard to how
exceptions are handled, once some real fixtures exist.

data can handle a string, a string indicating a file, and a data
structure.