Fix possible deadlock with bounded pools (TORQUE-1188)

The zero-downtime deployment work done for TorqueBox 3.0.0 introduced
the potential for deadlocking when borrowing / returning runtimes to a
bounded pool. This fixes that issue by splitting a single restart lock
into separate borrow and return locks so that borrow and return don't
lock with each other, and instead only lock with the restart action.
Ensure we don't publish incrementals from 3.0.x branch
Upgrade to JRuby 1.7.9 (TORQUE-1193)
Update to JRuby 1.7.10 (TORQUE-1193)
Try to bypass CloudBees maven mirror
Run finalizers after the zero downtime specs
Don't create so many unneeded JRuby runtimes in the zero downtime specs
Fix bad boolean logic on restart-all zero downtime spec
Only create Sessions in ServletStore if needed (TORQUE-1198)

Previously we created a new Java HttpSession on every request when our
ServletStore was used, and now we only create a new one when data gets
written to the store.
Remove locking from the request path with shared pools (TORQUE-1200)

This removes several sources of locking that were present in the
request path with shared pools - locking when borrowing / returning
Ruby runtimes, locking inside JRuby from initializing RubyIO
instances, and locking from JRuby when retrieving the JRubyClassLoader.

With these changes I see about a 50% improvement in top-end
performance for basic Rack apps. Most applications won't see this
performance boost, since our locking probably wasn't the bottleneck,
but for high-throughput and high-concurrency users this should speed
things up nicely.
Remove potential race condition from rake_spec integration test
Let the JBoss clustered session manager handle session expiration (TORQUE-1201)

Expiring keys behind the clustered session manager's back in
Infinispan leads to early session timeouts and in certain conditions
errors upon restarting a clustered TorqueBox.

This change also removes the default expiration (of less than 2
minutes) for regular Infinispan cache keys, instead relying on Ruby
clients to specify a cache expiration when adding entries.
Fix TorqueBox.fetch('DLQ') (TORQUE-1189)

This also fixes TorqueBox.fetch('ExpiryQueue').
Clean up another source of random failures in zero_downtime spec