Define klein's behavior in terms of request.write being called after request.finish.

This is caused by either the client terminating the connection or a bug in the server.

The default behavior is to allow request.write to be called when a handler completes
successfully, and let twisted.web raise it's RuntimeError.

However, the processingFailed code bath has been changed to guard against
error handling being called when a request has already completed.

This also allows this pattern:

@route("/")
def handler(request):
    d = someOperation()
    request.notifyFinish().addCallback(lambda _: d.cancel())

    return d

Which will effectively cancel someOperation when the client the disconnects,
while the handler is waiting for the result of someOperation.
Test case for write after connectionLost.
Fix the connection Lost test so it doesn't hang.
Catch the exception from request.write synchronously and don't return the failure from processing_failed.
Log unhandled errors while processing requests that have already finished.
Remove deferred debugging
Merge branch 'master' into finished-requests

Conflicts:
	klein/test_resource.py
Add tests for handling deferred cancellation and also cancelling the deferred returned to klein by the handler if the connection is lost.
Merge branch 'master' into finished-requests

Conflicts:
	klein/test_resource.py
Merge branch 'master' into finished-requests

Conflicts:
	klein/test_resource.py
Actually resolve conflicts.
Merge pull request #11 from twisted/finished-requests

Request.finish called on a request after its connection was lost