1. Added ruby22 and jruby tests to jenkins.
2. Added javascript tests to jenkins.
3. Added golang tests to jenkins.
4. Removed ruby19/ruby20 tests from travis. Support for ruby 2.0 has
   ended since 2016/02/24.
   https://www.ruby-lang.org/en/news/2016/02/24/support-plan-of-ruby-2-0-0-and-2-1/

Change-Id: Ie984b06772335352a4be7067ab2485f923875685

Update travis tests for Java.

1. Set JAVA_HOME so mvn can pick up the correct java version.
2. Remove jdk6 tests. It has been broken for a while and remain undetected as
   mvn is actually using java 7 to build the code. Given that we have
   set -source and -target to 6 in the pom.xml and the built .jar
   should be usable by java 6, having a dedicated java 6 test doesn't
   seem necessary (assuming very few Java 6 users want to compile protobuf
   Java from source).

Change-Id: I4f14da772632df3e47801f180198242b306c3f0f

Add missing files in EXTRA_DIST and add a test.

Change-Id: If80725402173cdf50969cb08e7fe5affe3532fb2

Versioning Java GeneratedMessage class

Use the dotnet-release package feed for Travis.

JavaScript: Make implicit defaults consistent with explicit defaults

See https://github.com/dotnet/core/issues/227 for background.

Change-Id: I56a6cce613462794f172ff2e62b25d8a9fc162f3

Change-Id: I991396ac6e51e32f3ab1daa501d625f34c3ecb04

Change-Id: Ib2bb5042deaabdf452d5be2ad1ce40d739ad8d1b

JavaScript: segregate references to binary functionality

Include javadoc/source in Java release packages.

Also fixed javadoc errors.

[ci skip]

This change will help us separate binary support into
separate files, because we only refer to binary serialization
functions in the actual binary serialization paths.

Added 3.0.0-beta-4 changelog.

Change-Id: I43f7e04a53d1445dfa86db310bdb18ceb446398c

Use public methods to fetch oneofs in generated code.

When building into frameworks, the generated code doesn't always have direct
access to the proto internals.  Instead of opening up the access, just use the
public method to fetch the correct oneof.

Fixes https://github.com/google/protobuf/issues/1789

Change-Id: Ic07a7c664930209974244c66885d672288982610

Exposes the currently registered extensions for a message and removes the internal sortedExtensionsInUse

Uses head version of rvm to avoid shell_update_session not found error

Fixes #1786 

Change-Id: I997012e7e9b58d9ec8b2f59429d71c98d81aa40d

Fix compatibility issues for the future GeneratedMessageV3 change.

Currently some public API methods are defined in GenreatedMessage.java
and they have a generric return type:
  class GeneratedMessage {
    class Builder<BuilderType extends Builder<BuilderType>> {
      public BuilderType setField(...);
      public BuilderType setExtension(...);
    }
  }
With these definitions, the compiled byte code of a callsite will have
a direct reference to GeneratedMessage. For example:
  fooBuilder.setField(...);
becomes:
  ##: invokevirtual // Method Builder.setField:(...)LGeneratedMessage.Builder
  ##: checkcast     // class Builder

This will prevent us from updating generated classes to subclass a
different versioned GeneratedMessageV3 class in the future (we can't do
it in a binary compatible way).

This change addresses the problem by overriding these methods directly
in the generated class:
  class Foo {
    class Builder extends GeneratedMessage.Builder<Builder> {
      public Builder setField(...) {
        return super.setField(...);
      }
    }
  }
After this, fooBuilder.setField(...) will be compiled to:
  ##: invokevirtual // Method Builder.setField:(...)LFoo.Builder

The callsites will no longer reference GeneratedMessage directly and we
can change Foo to subclass GeneratedMessageV3 without breaking binary
compatiblity.

The downside of this change is:
  1. It increases generated code size (though it saves some instructions
     on the callsites).
  2. We can never stop generating these overrides because doing that
     will break binary compatibility.

Change-Id: I879afbbc1325a66324a51565e017143489b06e97

Merge C# changes from master to 3.0.0-beta4

This also updates the version number to 3.0.0-beta4

We now just perform the optimization within AddRange itself.

This is a breaking change in terms of "drop in the DLL", but is
source compatible, which should be fine.

(Also fix a few more C# 6-isms.)

This fixes issue #1730.