Shadowed variables can cause readability issues. Ensure a shadowed
variable isn't used in header files which may be used in a dependent
project that explicitly disables them.

* Cython's stack does not have .py file name. Only check filenames when end with .py for _CalledFromGeneratedFile()

Sync internal benchmark changes

Remove use of GOOGLE_FALLTHROUGH_INTENDED from protobuf.

Fixes #4277

Chrome is running into two issues with the use of this macro
in open-source protobuf (https://crbug.com/809157):

1. GOOGLE_FALLTHROUGH_INTENDED is defined to nothing on __APPLE__
   platforms, which blocks us from enabling -Wimplicit-fallthrough
   on Mac and iOS. (We use a hermetic self-built modern clang,
   so whatever Xcode bug that exclusion might be for doesn't apply
   to us.)

2. It's in a public header file, and it's included in a public header file.
   When clang suggests adding [[clang::fallthrough]], it checks if it knows of
   a macro expanding to that and if so, suggests inserting that. Since lots of
   chrome code includes protobuf headers, it often suggests inserting
   GOOGLE_FALLTHROUGH_INTENDED (from protobuf) instead of the correct
   FALLTHROUGH (from chrome's base).

Since the fallthrough doens't do anyting useful, just remove it.
Long ago, this might have had perf impact, but d64a2d99 added a
parsing fast path that calls this switch as slow fallback, so it should
be off the hot path nowadays.

No intended behavior change.

This is the public version of internal change 184824132.

Various CMake Update

Bazel: Support building with Java 9

Upgrade benchmark submodule

cf https://cmake.org/cmake/help/latest/policy/CMP0048.html#policy:CMP0048

We follow the findProtobuf.cmake naming convention
to ease the use of protobuf as cmake subproject

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.