Rethink cookie upgrades

In future versions we should rework how [cookie upgrades](https://github.com/aidantwoods/SecureHeaders/blob/master/docs/v2/protectedCookie.md) are handled.

Sites which care about security related headers being reliably delivered should already be using HTTPS on all their pages – which means that HTTP cookies shouldn't be a thing. Adding `Secure` to all cookies seems like a pretty damn easy win. (this would replace our current approach which is only slightly better than a whitelist). For cookies that must be sent over HTTP, we can permit cookies to be manually deselected from this upgrade.

I think this approach may be valuable for all settings though: it adopts a "permissions" view of the world where everything is disallowed by default, and the developer must actively opt-in to less protection. i.e. instead of having to remember to think about "we must disallow JavaScript from accessing a cookie", developers should instead think "we should grant JavaScript access to this cookie".

My current thinking is the following:
* All cookies receive the `Secure` flag by default.
* All cookies receive the `httpOnly` flag by default.
* All cookies receive the `SameSite=Lax` flag by default.
* Allow manual exceptions to be written for all of the above based on cookie name, i.e.
* Explicit opt-in for cookies to be allowed to be sent over HTTP

* Explicit opt-in for JavaScript to be allowed access to a cookie

* Explicit opt-in for cookies to be allowed to be sent when not using top-level cross-origin navigations

* Allow specific cookies to be marked as "write cookies", which will upgrade the SameSite setting to `SameSite=Strict`. These are cookies which (if your site can be built to allow for it) should be reserved for granting write permissions to a particular user. `SameSite=Lax` cookies are perfectly okay for where the user need only *read* information.

There is a section in the [SameSite cookie spec](https://tools.ietf.org/html/draft-west-first-party-cookies-07#section-5.2) detailing a scenario where lax would be used for read permissions, and strict would be used for write permissions. Scott Helme has also done a nice explainer on using different cookies for read/write permissions in [CSRF is dead](https://scotthelme.co.uk/csrf-is-dead/#strict).

If you're developing a new app – this is something you should definitely look into in addition to current CRSF mechanisms (when all browsers have added support for SameSite it might be possible to ditch CSRF form tokens, but that is way in the future!).