Introduced the securityPolicy member of the Yesod typeclass, added tests...

..., and updated documentation and scaffolding
Yeah, I'm conscious of that, and I really wanted to find a way to do this that wouldn't have that effect, but I couldn't. For one thing, I wanted to preserve backwards compatibility for users that already have a scaffolded site. Also, I wanted the default site to continue to allow http. Further, I didn't want to change any types of existing methods, again for backwards compatibility.  Finally, and this is really the core issue, implementing a firm ssl-only policy requires changes not just to how cookies are set, but also to how headers are set, which is something I couldn't see how to control from within the type context of the `makeSessionBackend` method alone - from what I can see, it needs to be done both there and in `defaultYesodMiddleware`.  

An alternate approach that would avoid the risk of accidental overrides would be to nix `SecurityPolicy` and leave the onus on users desiring more security to make timeout-coordinated calls to `makeSessionsSslOnly` in their implementation of `makeSessionBackend` and `applyStrictTransportSecurity` in their implementation of `defaultYesodMiddleware`.  That has its own issues, since we have no control over whether users actually do implement these two things in lockstep.

On the one hand, there are some valid cases where you would want to have secure-only cookies and not have a strict-transport-security policy.  On the other, for users that know they need this level of configurability, I've already made the applyStrictTransportSecurity and makeSessionsSslOnly methods public, so that they can use those separately in their own implementations if they know they need to.  

In the end, I think it's basically a matter of opinion which effect (accidental overrides or uncoordinated security implementation) is more pernicious.   I'd be happy to PR an alternate design that opts for the latter if you're interested in seeing that.