Don't put generate() method on store object per request, refactored Session.regenerate() implementation

While implementing a session store for connect I got bitten by the Store.generate() method. This method is added to the store object by the session middleware _per request_.

To test my store implementation I had copied session.test.js to my project. I modified the tests to use my store implementation instead of MemoryStore. Crucially however I decided to instantiate one store object and pass that to all tests.

Unexpectedly the test 'test req.session.regenerate()' kept failing on line 280 with the message:

_SID matched after regenerate()_

After a long guru meditation I figured out that my singleton store object was pimped with a new generate() method on each request! After staring at middleware/session.js for a really long time it dawned on me that the generate() method placed on the store object is coupled to the scope of that session middleware instance. Hence, the generate() method called in Store.regenerate() was put there not by the test in question but by another one (which is why the session in the test wasn't regenerated.) This doesn't cause any difficulties in connect since session.test.js instantiates a MemoryStore object per test.

In short, it's not done to change the state of a singleton object with state that's specific to one request. Neither should state belonging to one request be kept around after the end of the request (which is what happened.) In this pull request you'll find a refactored middleware/session.js that leaves the store object alone 
 and instead couples all state required to regenerate the session to the Session object (which doesn't outlive the request scope.)

Thanks for taking my contribution into consideration.