Transparently upgrade signed cookies when setting secret_key_base

Re: #9740

This pull request introduces a new `UpgradeLegacySignedCookieJar` that is automatically used instead of `SignedCookieJar` when both `secret_token` and `secret_key_base` are present.

Currently, signed cookies generated by a Rails 3.x app will be invalidated by setting `secret_key_base`. This new cookie jar avoids this issue by transparently upgrading legacy signed cookies much like the `UpgradeSignatureToEncryptionCookieStore` does for legacy cookie-based sessions.

I noticed this issue when upgrading Basecamp to Rails 4 and I've avoided setting `secret_key_base` pending a fix for this issue. 

@neerajdotname kicked things off and @jeremy provided some guidance along the way. Thank you!

@spastorino asked to be notified when this pull request is ready, so here we go! 

This PR also introduces a `ChainedCookieJars` module in response to this commit 2b773e148b56e0cff3b07ef1902311688fb9fed8. @jeremy suggested this would be an improvement in that is eliminates some duplication, and I agree. This ensures that chained cookie jars will always be initialized using the correct options. 

@jeremy and I also discussed and agreed that it makes sense to remove the `method_missing` calls introduced in that same commit as the methods have not been deprecated, but rather have simply been removed. I think the `method_missing` calls added unnecessary confusion -- better to just raise an exception which should be self-explanitory.  

--

On a somewhat separate note, @spastorino, I'd like us to consider tweaking the way that the session-based cookie upgrade process works. I'm thinking we could allow the user to leave their app configured to use `session_store :cookie_store` instead of asking them to change to `session_store :upgrade_signature_to_encryption_cookie_store`.

I think we can assume that the user wants to avoid invalidating legacy cookies when upgrading. We can tell if someone is upgrading by the presence of the legacy `secret_token` . So, much like this PR does, perhaps we could detect this state and switch to using the new `upgrade_signature_to_encryption_cookie_store` automatically? 

Let me know what you think about this PR and about this possible additional improvement to the cookie-based session upgrade process. I'm happy to work up a PR for that separately, but I thought it would be smart to bring it up now.