Properly background singleton methods [TORQUE-891]

This allows #always_background to handle class methods as well, and
adds a #background class method to allow proxying class methods that
aren't always backgrounded.
Properly set multi-value HTTP headers under Ruby 1.9 mode (TORQUE-937)

Rack separates multiple values for the same header by newlines and
it's up to us to separate this out into multiple response header
entries all with the same key and the varying values. We were
accidentally doing this when running under Ruby 1.8 mode but failing
to do this under 1.9.
Don't assume Ruby 1.8 when using the capistrano tasks (TORQUE-841)

We'll only write a Ruby version to the deployment descriptor if a user
explicitly sets a Ruby version in via app_ruby_version.
Choose wiser between modifying or generating a Rails app (TORQUE-913)

Instead of going just off the root directory's existence, check for a
config/environment.rb to determine if a Rails application already
exists in the given directory or if we need to create one.

Also fix a bug in the way we specified gems for Rails 2.3.x versions
in our template.
Add integs for Rails app generation (TORQUE-913)

As a necessary side-effect for testing Rails 3.2 application
generation, you can now set the environment variable RAILS_VERSION to
some RubyGems version string when running 'torquebox rails' and it
will pick that version of Rails to use with the generators. Example:

RAILS_VERSION='3.2.8' torquebox rails
Finish up first steps mac/linux section of getting started guide (TORQUE-925)
Add first step windows to getting started guide (TORQUE-925)
Generate .bat gem stubs for windows (TORQUE-940)
Clear up MPING vs TCPPING confusion in clustering without multicast docs
Upgrade to JRuby 1.6.8 (TORQUE-942)
Add TB features to Getting Started Guide (TORQUE-925)
Ensure TorqueBox can always find bundler/setup (TORQUE-944)

There is a case where booting TorqueBox via the torquebox binary or
rake tasks when an application's gems are installed via bundle install
--deployment where TorqueBox cannot find bundler/setup during
boot. Passing on the parent's Ruby load path to the booted TorqueBox
process fixes this issue.
Explain concurrency setting a bit better for msg procs (TORQUE-802)
Fix torquebox gem version # when running on CI
Update version to 2.2.0-SNAPSHOT
capistrano-support: work without jruby_opts or app_ruby_version set

Reading jruby_bin without jruby_opts or app_ruby_version set would throw:

    #<NameError: undefined local variable or method `jruby_opts' for #<Capistrano::Configuration:0x302b2c81>>
Merge pull request #107 from nilbus/capistrano-support-fix

capistrano-support: work without jruby_opts or app_ruby_version set
Set Ruby's CWD before initializing the runtime (TORQUE-951)

When initializing the runtime, torquebox-messaging gets required by
some of the injectable messaging objects. This commit ensures that the
current working directory is set for the Ruby runtime before
initializing the runtime so Bundler can find its Gemfile during
runtime initialization.
Update to Quartz 2.1.5 via Polyglot 1.7.4 [TORQUE-953]
Only pass bundler load path entries to the booted TB process (TORQUE-954)

Any other load path entries weren't strictly needed to fix TORQUE-944
and were causing the issues seen in TORQUE-954 by getting Ruby 1.9 and
1.8 libraries on the load path.