* Make HTTPHeaders more user-friendly
* Header name is a struct conforming to `ExpressibleByStringLiteral`.
Standard header names are available through static constants.
This allows to save some CPU on lowercasing and hash value
calculation.
* Original headers are stored until first modification. Iterator
of `HTTPHeaders` iterates over original headers while they are actual,
in other case it iterates over underlying mutable dictionary.
* Default subscript returns values of all headers with the same
name concatenated with comma [RFC7230, section 3.2.2], except
for "Set-Cookie" for which only first value is returned.
* As-is values of all headers with same name can be accessed
through subscript with label `valuesFor`.
* append() method is modified to accept dictionary literal.
replace() method is added.
* Split HTTPHeaders implementation to separate extensions
* Convert HTTPResponseStatus to a struct
* `HTTPResponseStatus` is a struct now. It is better then an enum
in this case because it could be possible to provide an alternative
reason phrase as allowed by RFC7231:
"The reason phrases listed here are only recommendations -- they
can be replaced by local equivalents without affecting the protocol."
* `HTTPResponseStatus` struct is smaller then enum. Struct's size(stride)
are 32(32) whereas enum's are 33(40).
* Removed conformance to protocol `RawRepresentable` because custom
reason phrases conflict with the message of `RawRepresentable`:
"With a RawRepresentable type, you can switch back and forth between a
custom type and an associated RawValue type without losing the value
of the original RawRepresentable type."
* Added conformance to `CustomStringConvertble` to provide an easy
conversion to HTTP status line.
* Added conformance to `ExpressibleByIntegerLiteral` to provide an
easy way to pass numeric value instead of `.humanReadable`.
For many server-side developers 200, 404 and 500 have much more
meaning then `.ok`, `.notFound` and `.internalServerError`.
* Added `class` property in conformance with RFC7231 recommendation:
"HTTP clients are not required to understand the meaning of all
registered status codes, though such understanding is obviously
desirable. However, a client MUST understand the class of any
status code, as indicated by the first digit, and treat an
unrecognized status code as being equivalent to the x00 status
code of that class..."
* Update API documentation for HTTPResponseStatus
* Modify type of HTTP status-code: UInt16 -> Int
`Int` better match Swift API guidelines then `UInt16` and
requires the same memory in struct because of alignment.
* Swiftify HTTPResponseStatus initializers
aleksey-mashanov
Tanner