That should be only on the CFlags. When using the compiler
as the linker driver, one may want to also call pkg-config to get the
cflags, but when invoking the linker, there should be no compiler flags.

Currently, downstream libraries such as RProtoBuf fail because
`-std=c++11` is required via `configure.ac`, but RProtobuf has no way
of knowing this by consulting `pkg-config --cflags protobuf`.

Signed-off-by: Xiang Dai <764524258@qq.com>

* Support rc version in update_version.py

* Exclude repeated and map fields from normalization

* Remove erroneous comments

* Remove unnecessary check for map type

* Add support for repeated/map fields, add tests

* Fix wrapper message in repeated/map fields in array constructor

* Address PR comments

* Removed unused code

* Update docs

Revert "Add stack overflow protection for text format"

This reverts commit 6dcd8109.

This performance optimization allows to skip reflection (in the is() method) when the message has been already unpacked once

* Modify how end tags are encounted in merge code (compiler)

* Modify how end tags are encounted in merge code (generated)

* Modify how end tags are encounted in merge code (library)

* Regenerate generated code through generate_descriptor_proto.sh

I tried finding an active repo on github with no success.  The only ProtoSharp I found wasn't related to PB at all.

* add more descriptive error messages to init methods

* add type errors test to Makefile.am

Document why no enum_extensibility is needed for Swift.

It already exists for wire and json formats

Fix below issue:
src/Makefile.am:210: warning: whitespace following trailing backslash
Signed-off-by: Xiang Dai <764524258@qq.com>

libprotobuf being targed before libprotoc was causing Visual Studio to fail in linking protoc.

* Fix GetErrno() to be const noexcept

* Removed noexcept

* Use set -ex
* Use -std=c++14 so -latomic can be found

* Fix python release build.
* Separate config.sh by platform
* Use KOKORO_JOR_NAME to determine the BUILD_COMMIT.
* Use -std=c++14 on MacOS so -latomic can be used.

The draconian heapcheck turns up memory leaks outside our control, such
as ones in libc and in the heapchecker itself. I think for an automated
test it makes more sense for us to use the "strict" heapcheck, since
that already passes and should only report leaks that are within our
control.

Updated googletest submodule to the most recent upstream commit

Update guava version to 26