In ActionDispatch::Session::DestroyableSession: instead of setting it to nil, assign the newly generated session-ID to the Rack::Session::Abstract::SessionHash after destroying it.

In Rails 3.2, the `ActionDispatch::Session::CookieStore` inherits from `Rack::Session::Cookie`. 

The other stores, like `CacheStore`, `MemCacheStore` or even `RedisSessionStore` ([link](https://github.com/roidrage/redis-session-store)) inherit from `ActionDispatch::Session::AbstractStore`.

However, there's a small piece where `ActionDispatch::Session::AbstractStore` does not behave like `Rack::Session::Cookie`: When destroying the Session via `destroy`, Racks implementation (and thus the CookieStore) [assigns a newly generated session-ID back to the SessionHash](https://github.com/rack/rack/blob/rack-1.5/lib/rack/session/abstract/id.rb#L85), while the implementation in Rails' `AbstractStore` always [assigns nil](https://github.com/rails/rails/blob/3-2-stable/actionpack/lib/action_dispatch/middleware/session/abstract_store.rb#L18).

Due to the fact that most people use CookieStore (i suppose), this may not have been noticed by now.

Newer versions of Rails (4+) don't patch Racks `Rack::Session::Abstract::ID` anymore with the [nil assignment](https://github.com/rails/rails/blob/3-2-stable/actionpack/lib/action_dispatch/middleware/session/abstract_store.rb#L18), so they don't have this Issue.

This patch assigns the newly generated ID back to the session-hash in `ActionDispatch::Session::AbstractStore`. 
This enables us to use the (new) session-ID after destroying it when not using the CookieStore.