Guard against no subscription in on_unsubscribe

Don't assume subscribe_to has been called
on a subscriber when we're unsubscribing it.
Bit longer sleep for slow machines running messaging_spec
Wrap javascript code in an array in Rack response

`File.read` returns a String. String does not respond to `#each` and is therefore not a valid response body for a rack response. The Rack spec makes this clear:

> The Body must respond to each and must only yield String values. The Body itself should not be an instance of String, as this will break in Ruby 1.9.

This just wraps the resulting String in an Array, which is standard practice for this sort of thing.
[TORQUE-1069] Make it possible to create queues and topic at runtime in the way they are created currently at boot time
[TORQUE-1053] Use QueueInstaller to create queues using TorqueBox::Messaging::Queue.start method

This commit fixes both issues. The newly introduced Destinationizer
service is now responsible for creating destinations (queues and topic)
across TorqueBox. It does not talk directly to the HornetQ server and it
utilizes the QueueInstaller (or TopicInstaller) classes from polyglot.

The change itself results in a small overhead when creating the queues
(two MSC services are deployed) but it's a trade-off to have the
destination creation process same across different deployment methods.

This way we end up with a consistent creation of the destinations, both
at deployment and at runtime.

Destinationizer itself executes the creation in an asynchronous way
returning CountDownLatch to optionally wait for the task completion.

Additionally the TorqueBox::Messaging::Queue and
TorqueBox::Messaging::Topic documentation was rewritten to use the
proper yardoc tags.
Merge pull request #152 from goldmann/TORQUE-1069-runtime-destinationizer

Fix for [TORQUE-1069] and [TORQUE-1053]
Merge pull request #154 from goldmann/master

Changes to the way scheduled jobs are created
Merge pull request #155 from jnicklas/patch-1

Wrap javascript code in an array in Rack response
Expose restart method on shared pools (TORQUE-819)

The restart method, currently exposed via JMX, allows you to send all
new runtime requests for this pool to a new JRuby runtime while
draining old requests off the old runtime.

This commit is enough to get zero-downtime deploy for new application
code in web, scheduled jobs, and messaging runtimes when they're using
a shared pool, which is the default in production mode. It probably
also works for stomplets but that has not been tested yet.

Similar work needs to be done for bounded pools and then something
wired up to look for tmp/restart.txt so this can be triggered outside
of JMX operations.
Don't put spaces before parentheses of a method call
Add support for :max_entries and :eviction in caches.
Uncomment and fix the eviction cache spec
Fix Rails 2 support after config.ru reloading changes for TORQUE-819
Fix NameError that occurs when dechunking a response that happens to
have content that looks like a term marker.
Fix sinatra after TORQUE-891 changes for zero-downtime web deploys
Add basic zero downtime deploy spec (TORQUE-819)

For now this only checks that web runtimes reload via JMX without
downtime.
Increase the default timeout to wait for a queue to start - buildhive is SLOW
Don't hardcode the default latch wait time in destination_spec.rb
Don't assume rack/reloader starts with INITIAL now that multiple specs use that app
Add zero-downtime deploy to bounded pools (TORQUE-819)

Both bounded and shared pools now have a restart() method exposed via
JMX for doing zero-downtime deploys of specific subsystems (web,
messaging, jobs, etc). The next step is to add a way to trigger the
pool restart outside of JMX.
Sometimes CI takes longer than 10 seconds to spin up a jobs runtime