[TORQUE-674] Allow runtime scheduling of jobs

This adds initial support for scheduling jobs at runtime:

TorqueBox::ScheduledJob.schedule('SomeJob', "*/10 * * * * ?")
TorqueBox::ScheduledJob.schedule('SomeJob', "*/10 * * * * ?", :name => "somejob", :description => "A simple job", :singleton => true, :timeout => "5s")

Please note that singletons are untested so far.

The job name is required, but if do not specify it a default vaule of
'default' will be used. Please note that there cannot be two jobs with
the same name for one deployment unit (application).

More technical stuff:

This commit removes usage of BaseRubyComponentInstaller and moves all
the still required method to a ComponentResolverHelper helper class to
use them also in services that modify services at runtime.

A new JobSchedulizer class was introduced which is responsible for
runtime jobs scheduling.

RubyJobProxyFactory was removed and the logic was moved to
BaseJobScheduler.

JobComponentResolverInstaller was removed, since we initialize component
resolvers at runtime now (see ComponentResolverHelper and
JobSchedulizer).

In JobSchedulerInstaller we install one or two JobSchedulers depending
on the environment. One in case of a regular, non-clustered environemnt,
two (a regular and a singleton one) in case we have a clustered
environment.
Use JobsServices names exposed in polyglot
Removed ScheduledJobInstaller. Moved all job creation to the JobSchedulizer service. Deploying jobs from deployment descriptors is done now when the JobSchedulizer is being started.
Integration tests for runtime scheduling of jobs
Added an option to remove a deployed scheduled job. The remove method is
executed asynchronously and does not return any value.

TorqueBox::ScheduledJob.remove('job.name')

The scheduled job integration tests were extended.
Even more javadocs and a new integration test to check scheduled job replacement.
Docs for scheduled jobs creation and removal at runtime.
More docs in the Ruby code
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)