Working WSGI middleware

    The existing interface specification of ``Detector`` and ``Interceptor``
    does yot yield a clean use case for WSGI middleware. The constructor of
    ``Detector`` (i.e. ``Detector.__init__()``) takes the ``environ`` (HTTP
    request) as an input parameter. For WSGI applications, however, the HTTP
    request is *not* available at the global scope, but only as an input to
    the application's ``__call__()`` method.

    This means either (i) the ``Detector`` object needs to be constructed
    within the WSGI middleware's ``__call__()`` method, or (ii) the
    specification of ``Detector.__init__()`` needs to be changed.

    For option (i), the WSGI middleware needs to have access to all 6 parameters
    required by``Detector.__init__()`` and this greatly violates the decoupling
    and encapsulation principles of OOP.

    For option (ii), the ``environ`` (HTTP request) need to be supplied to
    ``Detector.detect()`` instead of ``Detector.__init__()``. This will make a
    ``Detector`` object stateless with respect to the HTTP request.

    Starting from 0.0.6 at the ``develop`` branch, the implementation of
    ``Detector`` is based on the above-mentioned option (ii), and it breaks
    backward compatibility of ``Detector`` intentionally.