Add fields and field annotations to jruby.
Use ordered hash map to ensure fields are defined in order specified.
Fix issues with java_signature for parameters.
Better fix.
Update testing doc.
Add field annotation.

This allows a seralization objects to be constructed in ruby.
Formatting.
Correct readme.
Fixing hashing consistency across JVM instances.

Several of the core JRuby classes calculate hash codes based on java or ruby
object ids. This doesn't produce consistent hashing across JVM instances, which
is needed for distributed frameworks. For example, Hadoop uses hashCode values
to distribute keys from the map phase to the same reducer task (partitioning).

This commit adds hashCode (and ruby's hash method) implementations for
RubyBoolean, RubyNil, and RubySymbol. RubyBoolean and RubyNil simply return
static, randomly-generated hashCode values that are hard-coded. This replaces
the default java Object#hashCode.

For RubySymbol, the previous implementation of hashCode returned the symbol's
id, which could be different depending on the order in which symbols are
created. This updates it to calculate a hashCode based on the raw symbolBytes
like the RubyString implementation, but with a RubySymbol-specific seed and
without the encoding addition for 1.9. This value is calculated when symbols
are instantiated so the performance impact should be minimal.

This commit also adds a RubyInstanceConfig setting and CLI option for
consistent hashing, jruby.consistent.hashing.enabled, which controls whether
the Ruby runtime's hash seeds (k0 and k1) are generated randomly. When set to
true, they are set to static values. These hash seeds are used to hash
RubyString objects, so this will make string hash codes consistent across JVMs.

(later commit...)

Updating hashCode implementations.

Per discussion on the last commit's pull request [1], updating the
implementations of hashCode for RubyNil and RubyBoolean. Now the hashCode
behavior for nil and booleans will only change when consistent hashing is
enabled. Adds a hashCode instance variable to RubyBoolean and RubyNil that is
set in the constructor to the Object#hashCode value (using
System.identityHashCode) or a static value.

[1]: https://github.com/jruby/jruby/pull/590
Fix string concatenation with a number as per rubyspec behaviour.

Following https://github.com/tychobrailleur/jcodings/commit/8536b4fdeecf3dec31ca868803654b3ab7829915, the incorrect behaviour of String#concat with
a number was made obvious by throwing an EncodingException.  MRI changes
the encoding of the String if the concatenated codepoint is within
ASCII-8BIT range, and throws a RangeError otherwise.
Fix precision issues in Time by avoiding conversions to nanoseconds.

Calculations using Time are done to the nanosecond.  When using dates,
the Unix time converted into nanosecond is too big (in absolute value)
to fit in a `long`.  The idea in this fix is to separate the millisecond
calculation from the nanosecond one to avoid converting these dates
into nanoseconds.
Remove useless casts.
Fix nanosecond precision for minus operation.
Synchronize profile printing.

This avoids interleaving/garbling of profiles from multiple threads.
Fix RubyString#byteslice on substring.

As value.getBegin() already managed by makeShared19(), the method
byteSubstr() need not take it into account.
Fix IOInputStream single-byte read

Java does signed type conversions by default. Thus, any bytes above 127
resulted in negative return values, which where either illegal return
values or signifying end of file.
Perf improve Enum#next by using SyncQueue instead of Exchanger.

Conflicts:
	src/org/jruby/RubyEnumerator.java

I am restoring this change for perf and because we have some time
to let it bake and ensure it does not regress the fixes for
Enumerator#next that were incorporated in 1.7.4.

The Exchanger-based impl appears to have significantly more
context-switch overhead than the SynchronousQueue version, perhaps
due to the bi-directional nature of Exchanger (more coordination
required for the hand-off).

All tests appear to pass and the original bug report's example
cleans up the abandoned "nexter" correctly.

Benchmark:

loop do
  puts Benchmark.measure {
    enum = (1..10_000_000).each
    begin
      enum.next while true
    rescue
    end
  }
end

Before (Exchanger impl):

  9.210000   5.840000  15.050000 (  9.525000)
  8.770000   6.300000  15.070000 (  9.806000)
  8.270000   5.770000  14.040000 (  9.074000)

After (SyncQueue impl):

  7.260000   0.050000   7.310000 (  3.560000)
  6.290000   0.060000   6.350000 (  3.162000)
  6.130000   0.050000   6.180000 (  3.085000)

Versus lightweight-threaded implementations:

Ruby 2.0:

  9.490000   0.010000   9.500000 (  9.492637)
  9.530000   0.000000   9.530000 (  9.537268)
  9.410000   0.020000   9.430000 (  9.429057)

Ruby 1.9.3:

  9.150000   0.010000   9.160000 (  9.160083)
  9.190000   0.010000   9.200000 (  9.187712)
  9.150000   0.000000   9.150000 (  9.153203)

Rubinius:

  6.442284   0.024857   6.467141 (  6.378807)
  6.350513   0.023981   6.374494 (  6.529533)
  5.870183   0.023033   5.893216 (  5.883422)
The removed spec caused a new exception to be in flight by
attempting to do a hard return from a class body, which is not
valid in Ruby. Because the return was initially propagated as a
non-local return jump, it appeared to pass or terminate specs
without erroring. When running under rake, the eventual exception
would bubble out and cause rake to fail the build.

Fixes 746.
Exclude TestPathname#test_lchmod form mri 1.9 test suite, it fails on travis
Grab reference to thread once.