Add HTTP 419 support to requests.codes

Very simply, I would like to have HTTP 419 status code represented as a constant in the `requests.codes` module, perhaps as `requests.codes.AUTHENTICATION_TIMEOUT`.

While this code is not officially (to my knowledge) part of an RFC / standard, it seems to have colloquial use / adoption on many Internet-facing web services.

Here's another framework who is considering this support (granted, the context is a bit different WRT requests):
GetBlimp/django-rest-framework-jwt#158

I'll post a basic PR to illustrate the request; no pressure to merge it as I am unsure what requests' policy on RFCs/standards is (whether or not dogmatic adherence thereto is a tenet/goal of this project).

> whether or not dogmatic adherence thereto is a tenet/goal of this project

"dogmatic" is unnecessarily adversarial in this context and it is setting yourself up for rejection.

---

We adhere to RFCs as best we can, but we also have edges where we allow for behaviour that isn't strictly RFC-compliant. Those areas are most frequently areas where we need to be smarter for security or slightly more like a browser. Our status code listing isn't something we're very stringent about but we do like to see actual consensus and wide-spread use. We also, however, support multiple reason phrases per status-code. So adding this one wouldn't preclude us from also supporting whatever the real standardized/accepted phrase becomes.

All that aside, it'd be helpful to know what benefit you see from `requests.codes.AUTHENTICATION_TIMEOUT` existing. As far as I can tell, there's little to no benefit, especially in the context of other libraries adopting it. So knowing why you would like this is far more valuable than knowing that you would like it.

I was not _trying_ to be adversarial. I've merely dealt with different philosophies across projects -- some factually choose to be _dogmatic_ in their approach to problem solving as a way of defining structure --  this word should be taken in an objective context which is difficult to convey over such a flat, unexpressive medium as this. I intended to leave room for the authors / maintainers to express their stance (without such foreknowledge on my part) however they like... enabling me to figure out the next step in solving my own software development problem(s).

A bit more about my use case:

My team has built a REST API which uses the "Bearer Token" authorization model. I have various consumers, one of which is a client based on `requests`. That REST API will return various status codes depending on the semantics of the response to a given request which requires authentication and authorization:

- HTTP 401 Unauthorized: when no token is given _or_ an invalid/unknown token is given by the requestor
- HTTP 403 Forbidden: when a valid, known token is given by the requestor (a client is thus identified/authenticated) but the requested resource requested falls outside their set of allowed resources (permission denied to the known client)
- HTTP 419 Authentication Timeout: when an _expired_ token is given by the requestor

The case of submitting an _expired_ token is special, in that clients may choose to use the HTTP 419 status code value (instead of parsing and interpreting a potentially changing string in the response body of an HTTP 401 response) in order to more conveniently make a decision on what to do next.

It seems easiest and least time consuming for those involved for the maintainer to wait for a standards body to make the decision on this particular response code.