[packaging] flag files in /etc as configfiles

This prevents them from getting overwritten when the logstash deb/rpm is
upgraded.
[packaging] minor RPM improvements

 - add time and commit id to package revision number
 - include url and description
[packaging] install only one copy of logrotate.conf
[packaging] depend on default-jre-headless

On debian/ubuntu, "default-jre" will pull several audio and GUI libs by
dependency, which aren't required to run logstash.
[packaging] adapt previous patchset to new .VERSION.mk

To recap, the goal is to keep the commit sha1 in the package release
number after the always-incrementing timestamp, and not in logstash's
version number.

Otherwise, we risk having dpkg/rpm believe the package will be
downgraded in the case let's say you have an 1.2.3.dev-abc123 version
which arrives after 1.2.3.dev-def456.
Try to solve the 'multi ruby' problem in bundler by having each
ruby write to its own Gemfile.<ruby version>.lock file.
- Add Gemfile.jruby-1.9.lock
Merge pull request #831 from jordansissel/work-around-bundler

Work around bundler
Add two more gemfile.locks (ruby 1.9.3 and 2.0.0)

Yes. I know the file is named 1.9.1. I don't have time to explain! GET
IN THE CAR. LETS GO.
Merge pull request #832 from jordansissel/work-around-bundler

Add two more gemfile.locks (ruby 1.9.3 and 2.0.0)
Make require() threadsafe again.

Is there a unicode glyph for facepalm? Probably should be. Put it here.
Take palm. Apply to my face.

The patch for LOGSTASH-1223 had a crazy hack to work around
'require("openssl")' taking a super long time. Unfortunately, it also
made require() not threadsafe. Oops.

While poking at the problem, I found that doing
'require("shared/jruby-openssl")' before require("openssl") actually
makes it as fast without the threadsafety problem.

This commit should fix the following many bugs:
  LOGSTASH-1310, LOGSTASH-1519, LOGSTASH-1325, LOGSTASH-1522

The reason 'openssl' is implicated here is because of the monkeypatch.
The common factor in user-reported problems is that using the tcp input
while also running the web interface in the same process, and tcp input
loads openssl, which does bad things and causes the web interface to
fail to load libraries it needs (like base64).

Data:
    # Before this commit:
    % java -jar build/*.jar irb
    >> time { require("openssl") }
    => 1.763

    # Without the patch for LOGSTASH-1223
    % java -jar build/*.jar irb
    >> time { require("openssl") }
    => 17.715

    # With this change
    % java -jar build/*.jar irb
    >> time { require("shared/jruby-openssl"); require("openssl") }
    => 1.881

Similar performance solution without the thread safety problems.
Merge pull request #834 from jordansissel/fix-monkeypatching-require

Make require() threadsafe again.
Upgrade ftw

The only change in ftw is that it now only loads backports on ruby 1.8,
which should help speed up the startup time of any plugins (and web)
that use ftw.
Merge pull request #835 from jordansissel/upgrade-ftw

Upgrade ftw
Avoid having 'remote: /some/path' in the gemfile.locks

When using bundler's "gemspec" setting it hardcodes a
local path as the "remote". This causes every 'bundle install' or
similar invocation on any other workstation to change that file simply
because the remote has changed. Not good.

Work around it by evaluating the gemspec ourselves and generating the
gem dependency list from that.

Same effect, better result, I think.
Merge pull request #836 from jordansissel/work-around-bundler-more

Avoid having 'remote: /some/path' in the gemfile.locks
- Add rubysl library as a dependency if we're on rbx.
- Additionally, because some gem installations require rubysl (under
rbx), make gembag install it first before running bundler.
- add rbx
Merge pull request #837 from jordansissel/add-rbx-gemfile-lock

Add rbx support for dependency stuff...
[rabbitmq] Switch to March Hare 2.0

March Hare is the new name for Hot Bunnies.

2.0 release notes:
http://blog.rubyrabbitmq.info/blog/2013/12/05/march-hare-2-dot-0-0-is-released/

Logstash RabbitMQ plugins are not affected by the breaking API changes.