Bazel: Support building with Java 9

Upgrade benchmark submodule

Fix link markup in third party list.

Create std::string in Arena memory

Fixes: #4256.

Bazel@HEAD supports Java 9.

The current code has one single issue with Java 9 compliance: the usage
of sun.misc package. We add jdk.unsupported module with --add-modules
compiler option for now. Long term, the usage of non public API should
be avoided.

To build with Java 9, build custom bazel version and issue:

  $ bazel --host_javabase=/usr/lib64/jvm/java-9-openjdk build \
    --javacopt='--release 9' \
    --java_toolchain=@bazel_tools//tools/jdk:toolchain_jdk9 \
   :protobuf_java

Haven't been able to make a repo case, but this should "fix" the problem
by avoid it completely.

- Move readOnlySemaphore_ into the .m file so it isn't exposed in any
  header.
- Move GPBGetObjectIvarWithField() also to go with the new limited
  visibility on the readOnlySemaphore_.

The Undefined Behavior sanitizer flags one part of the unittests for this.
For default values for `bytes` we write a length on the front of a c-string
in the static data, apparently the compiler/linker doesn't always make this
4 byte aligned, so it get flagged for undefined/degraded performance. Avoid
this by using memcpy instead.

Fixes #4246
Fixes #4247

Propose kotlinx.serialization as 3rd party lib

'<:' is an alternate spelling for '['.

Has support for protobuf v2.

Add Vcpkg to C++ installation instructions for Windows

Fixes issue #1154 by noting that `vcpkg` contains protobuf. Potential improvements: also remark how to use `vcpkg` to get dependencies when building from source via CMake.

cmake: privately add sources to targets

Java: Generate warning free code

Removed using statements from common.h

Partially fixes #4230.

These statements pulled a bunch of symbols from the std namespace into
the global namespace. This commit removes all of them except for
std::string, which is a bit trickier to remove.

Remove broken link to code.google.com/p/protorpc

Remove broken link to RPC implementation https://code.google.com/p/protorpc/. Going to this URL displays a 404 error message, with no indication that the project has a new location or still exists.

Remove the use of BUILT_SOURCES

This will allow SourceLink as per #4179, and mean that we can use C#
7.0 language features in the library (but not in generated code).
This does not affect which platforms we're *targeting*, so end users
won't see any difference.

It would be nice to update to 2.1.4, but AppVeyor's "Visual Studio
2017" environment is only 2.0.3.

Add Haskell implementations

The generated code for enums needs atomics support, so generate the
import instead of relying on it via transitive imports. This will
make future changes to this likely likely to break generated code
and runtime support are mixed.

Followup to https://github.com/google/protobuf/pull/4184.

Followup to https://github.com/google/protobuf/pull/4184, keep the
import to not break any existing generated code that isn't regenerated
when they update to the newer protobuf code.

Add Awake Security's Haskell Protobuf and GRPC implementations

Drop java 6 support

Fixes #4220.

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

[BUILT_SOURCES](https://www.gnu.org/software/automake/manual/html_node/Sources.html)
is used with [Automake's automatic dependency tracking](https://www.gnu.org/software/automake/manual/html_node/Dependencies.html#Dependencies)
but doesn't work well in protobuf when cross-compiling. Their presence
causes maek to always generate them even when they are not requested
and as a result causes cross-compilation to fail because the built protoc
cannot be used to generate unittest protos (see: https://github.com/google/protobuf/issues/3912).

Removing it with explicit dependencies fixes the build issue when running
'make', 'make all', 'make install' at cross-compilation. It doesn't affect
'make protoc' because BUILT_SOURCES only works for the implicit targets
'all', 'check' or 'install'.

fix typo in FieldMaskTree.java comment

* Migrate away from deprecated OSAtomic APIs.

Public sources get added to dependencies of the target as well which can
cause duplicate symbols.

By default, unknown fields are preserved when parsing. To discard
them, use a parser configured to do so:

var parser = MyMessage.Parser.WithDiscardUnknownFields(true);