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.
Don't log all the attempts at requiring torquebox_init.rb
Temporarily increase sleep timeouts on new runtime job specs until a better long-term solution is implemented
Increase default max pool size for jobs / messaging in development (TORQUE-1059)
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.
Drop inject and add TorqueBox.fetch (TORQUE-1054, TORQUE-1056)

Convert all internal uses of fetch to TorqueBox.fetch and modify most
integration tests to use TorqueBox.fetch, leaving a couple using the old
'include TorqueBox::Injectors' to ensure backwards compatibility.

Since TorqueSpec still uses inject, we've retained a tiny stub in injectors.rb
of TorqueSpec::Daemon#inject that just calls TorqueBox.fetch.
Store the Rails template.rb inside torquebox-rake-support gem (BZ-923892)
Move InjectionError so that it's in scope when used.
Merge pull request #147 from johnae/master

Move InjectionError so it's in scope when used
Add integration test to ensure InjectionError is raised for invalid injections
By default make the scheduled job a singleton job
Now the asynchronous calls to schedule or remove a ScheduledJob return
ExecutorCompletionService which can be used to determine if the task
(scheduling or removing the job) is finished.

We use the pool(long, TimeUnit) methond in schedule and remove methods
in the TorqueBox::ScheduledJob module. By default we'll wait 10 seconds
for the task to finish, but it's configurable by passwing the :wait
parameter to the schedule or remove calls. Specified value must be in
miliseconds.

TorqueBox::ScheduledJob.remove('JobClass', :wait => 5_000)
Make the remove and schedule calls remove true when the task finishes
successfully and false in case of timeout.

Updated docs to reflect the changes.
Fix the location of the module
Added back installing MBean for the job service
Try to force the job replacement timeout spec to actually timeout
Proper injection usage in AnotherSimpleJob class
[TORQUE-257] Provide support for 'at' jobs