Introduces a TypeSafeSession middleware which can be passed to a user's Codable Routing handler, and on which the user can define the data types that their application requires in the session.

The requirements of a TypeSafeSession type are:

• The type must conform to TypeSafeSession, which itself conforms to Codable. Any session properties must therefore be Codable.
• The type must be a struct or a final class. The class must be final because the TypeSafeMiddleware protocol includes a static function with a Self type reference. The guide will include an example of how to mutate the session in a handler if it is a struct (since it is passed in as a function argument which is a let constant).
• If multiple TypeSafeSession types use the same cookie name, they must also use the same cookie secret, as they will share a single session cookie.

When defining a new TypeSafeSession, the user must define:

• An instance property sessionId: String
• A public init(sessionId: String) that should construct a new, empty session
• A static let sessionCookie: SessionCookie that defines the cookie parameters (at minimum, the cookie name and secret)
• A static var store: Store? that defines how the session is persisted (if unspecified, defaults to an in-memory store).

An example declaration:

import KituraSession

// Defines the user's session instance data.
final class TestSession: TypeSafeSession {
    let sessionId: String
    init(sessionId: String) {
        self.sessionId = sessionId
    }
}

// Defines the configuration of the user's type: how the cookie is constructed,
// and how the session is persisted.
extension TestSession {
    static let sessionCookie: SessionCookie = SessionCookie(name: "TestSession", secret: "Top Secret")
    static var store: Store?
}

Dependencies

This PR depends on Kitura/Kitura#1274 (TypeSafeMiddleware implementation).

Design and rationale

We decided to require the user to define the name of the session cookie as well as the secret.

The existing Session middleware implementation defines a default name of 'kitura-session-id', however it is expected to be a global middleware (a single Session used by all handlers).

By contrast, it would be reasonable for a user to define multiple TypeSafeSession types for different parts of their application. If they want to share the same cookie they can (by setting the cookie name to the same value), however they must also set the secret to the same value. Due to this requirement, we felt it was sensible to make the user think about both values.

We departed from the CookieParameter array, instead defining a SessionCookie initializer with optional parameters. We felt this was more natural, and would otherwise have needed to extend the CookieParameter enum with name and domain fields. (domain was missing from the existing Session implementation).

We did not define HttpOnly, even though it is good practice, as it seems there is no way to set it independent of secure via the NSHTTPCookie API.