Re-use gevent.core.loop instance after hub destruction without loop destruction.

This pull request solves issue https://github.com/SiteSupport/gevent/issues/237. 

Currently, gevent may create multiple `gevent.core.loop` instances representing the same libev event loop. This can provoke a segmentation fault during garbage collection or during manual destruction of these loop instances: after the first of these instances has destroyed the event loop via libev's `ev_loop_destroy()`, the loop pointers of the other instances representing the same libev loop are invalid. The next API call referring to the already destroyed loop (which occurs latest during program exit) will result in segfault.

I believe the most straight-forward solution to this problem is to not allow the creation of multiple `gevent.core.loop` instances representing the same libev event loop via gevent API. The most important (only?) place to ensure this is the `gevent.core.loop` creation in hub.py. This pull request

- makes gevent temporarily store  `hub.loop` during hub destruction and re-use it upon the next hub creation (only if the loop isn't requested to be destroyed, too).
- consolidates the tests in `test__destroy.py` (more detail and complexity, more explanation)

Note that the new unit test will fail as long as `hub.py` erroneously calls `ThreadPool.close()` during `Hub.destroy()` (tackled in pull request https://github.com/SiteSupport/gevent/pull/235).