Deprecate this in favour of http-errors

[pluma]

http-errors seems to do the same thing except it's part of jshttp, which seems to be the closest thing to a standard collection of HTTP-related modules the node community has. As far as I can see the only real difference is that httperr includes some non-standard HTTP errors that the jshttp statuses module doesn't include.

I'm considering deprecating httperr in favour of http-errors to avoid redundancy/NIH. Does anybody see a reason not to? Is there anything httperr can do that isn't supported by http-errors yet?

[pluma]

There are some minor problems with http-errors that need to be addressed before I'm comfortable with deprecating httperr:

• Fix err.name to make stacktraces more meaningful. See jshttp/http-errors#10.
• More consistent CamelCasing of error names (I'mateapot, URITooLong, etc => ImATeapot, UriTooLong and so on). See jshttp/http-errors#9.
• Fix constructor names (use eval 😦 or code generation à la statuses 😐). See discussion at jshttp/http-errors#12.
• Replace __proto__ assignment and captureStacktrace with something that works outside V8. See discussion at jshttp/http-errors#11.
• Allow calling constructors without new? (already supported)
• Provide a mechanism of passing extra information (allowed methods for MethodNotAllowed, etc)? (not important)

I'll open PRs to propose fixes.

Some concerns httperr addresses are irrelevant:

• title (and any of the other derived attributes) is solved by statuses. If you want to find out the human-readable name of an error, just look it up there.
• non-standard error codes (e.g. 420 Enhance Your Calm) -- these can be added to statuses if they have any real-world value. Also screw twitter's old API, 420 may be funny, but you should be using 429.