Phs/shared jruby coprocessor environment

Break out `SharedJRubyEnvironment`, `SharedRunner`.  This lets us share `JRubyEnvironment`s and askari runner instances across region observer instances.  Things are reference counted with a gross lock to eagerly clean things up.

Reference counts for jruby environments are tallied by the containing jar name. Runners are tallied by the jar name and the askari application name (the `askari.name` parameter.)

The thread context class loader, which we need to set to skirt around an [HBase class loading issue](http://stackoverflow.com/a/18599300/580412), is now set & cleared more eagerly, plugging a leak.

Also be more vigilant about cleaning up thread locals, to allow a `JRubyEnvironment` to be garbage collected if there no live coprocessors referencing it.  This still does not seem to be actually happening (permgen is still building up) but when coupled with [this](https://github.com/jruby/jruby/pull/1391) change `jmap` shows no live references to any askari or jruby classes from dead coprocessors.

Askari drops its own use of thread locals, since the jruby `CONCURRENT` local context scope was giving us the desired effect already.