bugfix(errors): Allow 404 and 405 errors to have message body

According to RFC 7231 (which obsoletes RFC 2616) all 4xx error messages "Except when responding to a HEAD request, the server SHOULD send a representation containing an explanation of the error situation, and whether it is a temporary or permanent condition." (http://tools.ietf.org/html/rfc7231#section-6.5). Section 6.5.5 which is specific to the 405 message does not negate this; nor does section 6.5.4 for the 404 message.

This change set updates the 404 and 405 messages to make the representation optional so developers using Falcon can decide whether or not to provide it. By default the OptionalRepresentation mix-in that is introduced behaves like the NoRepresentation mix-in if the developers does not provide a description, thus keeping the existing functionality intact (e.g no breaking changes in functionality).

While this change set only changes 404 and 405 errors, the default functionality for all errors presently using the NoRepresentation mix-in should probably be the OptionalRepresentation mix-in instead so that developers can choose appropriate responses for the WSGI applications.
I'm not familiar with the history of new-style classes; I saw super() came in around 2.2 (https://docs.python.org/2/library/functions.html#super). I see that new-style did in 2.2 as well - https://docs.python.org/2/reference/datamodel.html#newstyle; I do see classes are derived from object.

So ultimately I don't think it would be an issue to start using super() in 2.2+ style; but as I noted in my original response (https://github.com/racker/falcon/pull/377#discussion_r20577334) that is not the style Falcon uses as a whole, so there becomes a code consistency issue.

This particular class is a little different too since the class it is replacing (NoRepresentation) doesn't have an __init__() as all. It was required here b/c of the needing 'description' initialized.