Subclass HTTPBadCSRFToken from HTTPBadRequest and have request.session.c...

...heck_csrf_token use the new exception.

This supports a more fine-grained exception trapping.

There's no possibility of a real namspace collision here, but should the name be something other than HTTPBadCSRFToken to avoid a possible brainspace collision with future http response codes?

Should check_csrf_token() really report itself when raising the exception or am I too used to shell?  What about case in the error text?

Should the docs for HTTPBadCSRFToken and HTTPBadResponse state the http error code?

Note that I was unable to get the big exception list in the docs to format properly without the additional blank lines around HTTPBadCSRFToken.  There might be a better way.

Note that while I plan to need this in the future I have no immediate need for this feature.  This was done more as an exercise in design and hacking the pyramid code than out of present need.