[TORQUE-1012] Eager loading for messaging is not working with ruby DSL and a shared pool
[TORQUE-1020] rake torquebox:archive fails on Windows
Don't load torquebox-core until after Bundler (TORQUE-1036)
Update to JRuby 1.7.3 (TORQUE-1037)
Fix a race condition for multiple services of the same class (TORQUE-1058)

This fixes a race condition where it was possible that we were
reloading a service's .rb file (and thus redefining that service
class) while simultaneously trying to initialze an instance of that
class, leading to errors on service boot. This is a fairly rare issue
and only occurs with multiple services deployed in a single
application that use the same class.
Only scheduled a job for execution after it's fully setup (TORQUE-1057)
Use a new thread when starting services that may block (TORQUE-1055)

This isn't the proper long-term fix for TORQUE-1055 but it will at
least avoid starving MSC threads for now.
Use a thread pool to executing all blocking MSC start methods (TORQUE-1055)
Services don't need to reload app environment before starting (TORQUE-1049)

Previously we were calling ActiveSupport::Dependencies.clear in Rails
applications before starting each service of an application. This
causes issues if two services are starting at the same time and we
clear everything out while another service is in the middle of
initializating. Because services can't be reloaded without undeploying
and redeploying the application, this was unnecessary and we no longer
call that method when booting a service.

Conflicts:
	modules/services/src/main/java/org/torquebox/services/component/processors/ServiceComponentResolverInstaller.java
Fix memory leak in dev mode for jobs / msg procs (TORQUE-1029)

Scheduled jobs and message processors were leaking memory at a
substantial rate in development mode when Rails 3.2+ was in use. This
possibly impacts earlier Rails versions as well but has only been
confirmed to be an issue on Rails 3.2.
Synchronize GlobalRuby#evaluate (TORQUE-1078)

When deploying multiple applications we were letting multiple threads
interleave their GlobalRuby#evaluate calls when resolving ERB in
-knob.yml files which could sometimes lead to
java.lang.ArrayIndexOutOfBoundsException. The root cause of the
exception seems to be a thread-safety issue in either the ERB library
or JRuby string concatenation, but this should workaround things for
now.
Instead of synchronization pass a new binding to each ERB eval (TORQUE-1078)