Move the request encoder API to Resource

[therve]

The new API merged at #104 is on Site, but it doesn't allow to selectively enable encoders on specific path. It's particularly important given the SSL/Zlib attacks on user-generated requests (see  https://bugzilla.redhat.com/show_bug.cgi?id=857051 for example).

[therve]

(In [35846]) Branching to 'encoder-resource-6031'

[therve]

Here it is!

[therve]

(In [36174]) Branching to 'encoder-resource-6031-2'

[exarkun]

Thanks. Just some minor doc issues:

1. Seems like EncodingResourceWrapper shouldn't bother talking about the private interface that is used to implement the behavior it provides (since we don't want to encourage users to do anything with this interface).
2. Would also be nice to see EncodingResourceWrapper be a little more explicit about what it does: (potentially) apply one of the encodings to the response body generated by the wrapped resource. Perhaps also worth mentioning encodings are not inherited by children of the resource.
3. in the Resource docstring, instead of "It serves 2 main purposes..." I would write "This serves 2 main purposes...".

That's all. Please fix these and then merge (if the  build results look good), thanks!

[therve]

(In [36181]) Merge encoder-resource-6031-2

Author: therve Reviewer: exarkun Fixes: #6031

Move the encoding mechanism logic in twisted.web from Site to a wrapper Resource, so that users can more selectively apply it. In particular, add a note in the documentation about SSL/zlib attacks on user-generated content.