Bump version to 1.3.1

Use AX_CXX_COMPILE_STDCXX macro to enable C++11 support in old compilers

This reverts commit 0585e053.

Now that we autodetect any needed flags to enable C++11 support with the
AX_CXX_COMPILE_STDCXX macro, we no longer need to force this in
.travis.yml.

This commit enables use of the AX_CXX_COMPILE_STDCXX macro from the
autoconf-archive (added in the previous commit), which automatically
adds needed flags to the CXX variable to enable C++11 support. This only
works and is only required on compilers that are both new enough to have
C++11 support and old enough to not enable it by default.

We call it with "noext" as the second argument (so that we get the "std"
C++11 variant on GCC) and "mandatory" as the third argument, since we
now rely on C++11 features as of 83c59e70.

Note that this macro is only called when we are building the compiler
(i.e., without --disable-protoc) so that the library can still be built
on ancient C compilers.

fix mingw compilation

Convert uses of protobuf's scoped_ptr.h to C++11 std::unique_ptr

Upstream protobuf removed scoped_ptr.h, which provided the scoped_ptr
that we depended on, in commit 67952fab2c766ac5eacc15bb78e5af4039a3d398
(https://github.com/google/protobuf/commit/67952fab2c766ac5eacc15bb78e5af4039a3d398).

This commit converts uses of scoped_ptr type to idiomatic C++11
std::unique_ptr, similar to the changes in the protobuf commit.

This has been tested on protobuf 3.0.0 (the version currently in Debian)
as well as the latest protobuf 3.6.1 release.

Add std:: to some types

Update Travis to use xenial, protobuf 3.6.1

The xenial Travis-CI environment uses a g++ version that is old enough
that it doesn't use C++11 or newer by default, so we have to force it by
setting CXX to "g++ -std=c++11".

This commit updates the base Travis-CI image from trusty to xenial,
which ships with a slightly more modern compiler.

This is required for compilation to succeed on debian jessie with g++
6.3.0.

Restore protobuf-2.x compatibility

The change in commit 712154b9 ("Bump
minimum required header version for proto3 syntax") uses functionality
only exposed by protobuf-3.x, breaking the build when compiling against
protobuf-2.x.

Since we still want to support building against protobuf-2.x, this
commit makes the proto3 syntax check in the file generator dependent on
building against protobuf-3.x.

ChangeLog: 1.3.0

Bump minimum required header version for proto3 syntax

The changes in #274 (proto3: make strings default to "" instead of NULL)
add a new symbol to the library and add an 'extern' declaration to the
protobuf-c header file.

Since the compiler may generate files that depend on that new
'protobuf_c_empty_string' declaration in protobuf-c.h, we need to bump
the min_header_version value that is written into generated header
files. But since the 'protobuf_c_empty_string' symbol can only be
referenced when generating proto3 syntax files, we only need to use the
stricter min_header_version value when processing a proto3 file.

Bump version to 1.3.0

Fix namespace errors when compiled with latest protobuf

The protobuf project removed "using namespace std" namespace pollution
from their stubs/common.h header file. This caused build failures for us
since we relied on their namespace pollution.

This commit updates protobuf-c to convert:

 'map' → 'std::map'
 'set' → 'std::set'
 'back_insert_iterator' → 'std::back_insert_iterator'

proto3: make strings default to "" instead of NULL

The spec talks about "empty string" and other languages like C#
return a zero length string and not null.
This is useful because when moving from proto2's "required string"
to a proto3's plain string we will be guaranteed that we
never get a null pointer.
The tradeoff is adding a special case to the library but avoiding
a lot of null checks in the calling code.
The current code is already special casing "" in pack_string.

Rework is_zeroish one more time

Update CMakeLists.txt

The "member" param cannot be NULL, so last patch was not correct.
However to be valgrind clean we need to cast to the right size.

Small cleanup in oneof handling

Fix proto3 "is zeroish" evaluation

Small cleanups: pass the oneof case param by value instead of by
reference and use an early return if the case does not match.

Make sure we actually include the proto3 generated header and
test nested submessages