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

In proto3 the default value is zero (NULL for pointers and 0 for
scalars). However when checking we still need to test by type
because poinetr types have an extra indirection.

Remove leftover FIXME comment

Add warning flags to my_CFLAGS

Here 'j' is used as a loop index and there's no need to re-declare it
inside this block.

Found with -Wshadow.

CMAKE_SOURCE_DIR -> CMAKE_CURRENT_SOURCE_DIR

Static build for Windows MSVC

proto3 support

Fix "Bad enums with multiple oneofs" (#251)

This commit fixes #251, which causes incorrect code to be generated when
there are multiple oneofs in the same message.

In #221, we added code to force int-sizing for oneof enums, but we only
set vars["opt_comma"] initially, before entering the loop over the
message's oneofs. This caused commas to be omitted when generating the
enums for subsequent oneofs after the first oneof.

This commit resets vars["opt_comma"] every time through the loop that
generates the enum declarations for the message's oneofs.

This commit fixes a problem identified in #251. When generating the
PROTOBUF_C__FORCE_ENUM_TO_BE_INT_SIZE directive at the end of the enum
values generated for a oneof, we inadvertently only included the
protobuf class name in the call to the directive. This breaks if there
is more than one oneof per protobuf class, which causes duplicate enum
names to be generated.

This issue is fixed by also appending the oneof's name to the protobuf
class name when generating the PROTOBUF_C__FORCE_ENUM_TO_BE_INT_SIZE
directive, which should cause unique enum names to be generated.

This changes the enum name that is generated, but these names are
implementation details since they are sentinel values that only exist to
force the compiler to size the enum type correctly.

(The test case for #220 is updated since that test relies on the
oneof implementation details in the code generator.)

Document and extend the effect of passing NULL to ..._free_unpacked functions

This makes __free_unpacked() consistent with free(), and simplifies
callers by allowing them to indiscriminately free message objects
without regard to whether they have been allocated or not.

Add test case for #220