JedisSentinelPool now takes care of multi failover

* Now Pool.initPool() call closeInternalPool(), instead of destroy()
** calling destroy() in Pool.initPool() may have side effect, and JedisSentinelPool did
* modify unit test to test failover twice (needs +1 slave)
** modify configurations for additional slave
Merge pull request #462 from HeartSaVioR/jedis-issues-459-cleaned

Let JedisSentinelPool take care of multi-failover (cleaned ver. of #460).

Pool class is just wrapper of GenericObjectPool, so initPool()'s behavior seems fine. But another classes that extends Pool may have additional things, and these have to clean up when destroy() called. JedisSentinelPool has additional things, MasterListeners, and destroy() cleans up MasterListeners. MasterListeners are independent from Pool(means internalPool) itself, so reinitialize internalPool should not affect MasterListeners. And if initPool() has to clean up additional things, extended classes are responsible to take care of it. In Pool.initPool(), it should not call destroy() methods. Because when using JedisSentinelPool object, JedisSentinelPool.destroy() called and affect MasterListeners. We can replace destroy() in Pool.initPool() to other method that cleans up internal pool. Modifying Pool class does not need restarting MasterListeners, and fix #459, and everything is OK. I modified unit test to failover twice and success. To run failover twice without external operation, master needs to have two slaves (another one). I configured Makefile and pom.xml, HostAndPortUtil, etc.