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

protobuf does not provide configured tarballs anymore, so we need
to run autogen.sh ourselves.

Same code of the proto2 test but with the corresponding proto3 file

This is a first cut at adding proto3 support.

As far as I understand protobuf-c already has pretty much everything
needed once it is built using a new version of protobuf itself.
The only missing thing is that in proto3 all fields are optional and
having to manually set has_foo is inconvenient.

This patch special cases the proto3 syntax files so that structs for the
bytes, enum and primitive fields do not emit the has_ field.

It also adds PROTOBUF_C_LABEL_NONE to the label enum that is used for
proto3 fields. When a fields has this label, the quantifier is not
consulted and instead the field is packed/unpacked depending on
whether it has a value different from NULL/0.

Make init_value const

rm argument fix for solaris

Relax autoconf constraint from v2.64 -> v2.63 (so that it works on SL6)

protobuf-c: fix: make dist

fixed cmake build if built as  part of an external project

remove .pb.{cc,h} in distdir instead of top_distdir in order to
prevent removing files from other projects when protobuf-c is
included as an autotools subproject.
Signed-off-by: Gregory Detal <gregory.detal@tessares.net>

protoc-c/c_message.cc: Force int size on oneof enums

http://lists.llvm.org/pipermail/llvm-foundation/2016-May/000020.html

travis-ci/travis-ci#6120

Fixes #220. Patch by Dave Benson from the mailing list thread.

Fix bigendian -Wunused-label warning

Fix ISO C90 -Wdeclaration-after-statement warnings

Fix -Wsign-compare warnings in int32_size()

From https://developers.google.com/protocol-buffers/docs/proto#optional:
If the default value is not specified for an optional element, a
type-specific default value is used instead: for strings, the default
value is the empty string. For bools, the default value is false. For
numeric types, the default value is zero. For enums, the default value
is the first value listed in the enum's type definition. This means care
must be taken when adding a value to the beginning of an enum value
list.

Prior to this change, protoc-c set the default enum value to 0, whether
or not 0 was the first value listed in the enum's type definition (or if
it even was listed at all).

Using the old "protoc-c" command directly is still supported
through a symlink.