This test fails, exposing a bug. As things stand, Redbird accidentally
moves to a new redis key each time `Plug.Session.REDIS.put/4` is called.

This stems from calling `Redbird.Key.sign_key/2` unconditionally
(as of 299906f), which results in signing the already-signed
user-supplied key.

We end up with a key with arbitrary levels of nested signatures.
This is bad in its own right (redbird isn't supposed to move to a new
key each `put`), but also leads to the key growing without bound,
as each new layer of signature results in a somewhat-longer key.

Eventually, this overflows the maximum length of 4096 bytes which plug
is willing to allow in a cookie, leading to a Plug.Conn.CookieOverflowError.

The function previously known as Redbird.Key.deletable?/2 is
now Redbird.Key.accessible?/2, and is used in put/4, get/3, and
delete/2.

A key is now signed exactly once, immediately after being generated,
and verified each time it is used. This fixes the bug described
in the previous commit, where the session key is re-signed
with each call to put/4, causing it to grow without bound and eventually
overflow.

Plug.Crypto defaults to a validity period of 24 hours.
Thus we effectively expire sessions after 24 hours, irrespective
of redbird's configured expiration time.

By passing our expiration time through as the max_age when verifying the
signature, we can avoid expiring sessions early when redbird is
configured to keep session for longer than 24 hours (as indeed it is by
default.)

The redis key sent in the cookie can't be trusted if it's unsigned, or
if it's signed incorrectly. We need to ensure that we don't allow
malicious users to set arbitrary redis keys.

Therefore, if the signature can't be validate we start over with a new
generated key in the same way as when the key isn't specified.