configure now has a "--enable-code-coverage" option, and if the
lcov/gcov tools are available a code coverage report can be built with
"make check-code-coverage".

this is mostly based on the AX_CODE_COVERAGE / GNOME_CODE_COVERAGE
macro:

    http://savannah.gnu.org/patch/?8451

but i also looked at knot-dns's code coverage implementation:

    https://github.com/CZNIC-Labs/knot/blob/master/m4/code-coverage.m4

and kevin lyda's pull request:

    https://github.com/protobuf-c/protobuf-c/pull/131/files

it's related to the RPC code, and that's been split out into
protobuf-c-rpc now.

this was inadvertently reverted when i was editing e9627054.

this adds a version guard like the protobuf C++ implementation. it
ensures that protoc-c and <protobuf-c.h> are from the exact same version
of protobuf-c.

this replaces the changes in Issue #53 with a slightly different way of
representing / retrieving the version number.

protobuf_c_version() returns the version of the *library* as a string.

protobuf_c_version_number() returns the version of the *library* as an
integer.

PROTOBUF_C_VERSION is the version of the *headers* as a string constant.

PROTOBUF_C_VERSION_NUMBER is the version of the *headers* as an integer.

[edmonds@fsi.io: resolve merge conflicts, add documentation]

rename PROTOBUF_C_FIELD_FLAGS_PACKED to PROTOBUF_C_FIELD_FLAG_PACKED.

rename ProtobufCFieldFlagType to ProtobufCFieldFlag.

wrap some particular long lines.

update documentation.

for clarity, use a "uint32_t" instead of "unsigned" for the 'flags'
field in _ProtobufCFieldDescriptor.

Originally, someone complained about protobuf_c_message_unpack() using
alloca() for the allocation of the temporary bitmap used to detect that
all required fields were present in the unpacked message (Issue #60).
Commit 248eae1d eliminated the use of alloca(), replacing the
variable-length alloca()'d bitmap with a 16 byte stack-allocated bitmap,
treating field numbers mod 128.

Andrei Nigmatulin noted in PR #137 problems with this approach:

    Apparently 248eae1d has introduced a serious problem to protobuf-c
    decoder.

    Originally the function of required_fields_bitmap was to prevent
    decoder from returning incomplete messages. That means, each
    required field in the message either must have a default_value or be
    present in the protobuf stream. The purpose of this behaviour was to
    provide user with 100% complete ProtobufCMessage struct on return
    from protobuf_c_message_unpack(), which does not need to be checked
    for completeness just after. This is exactly how original protobuf
    C++ decoder behaves. The patch 248eae1d broke this functionality by
    hashing bits of required fields instead of storing them separately.

    Consider a protobuf message with 129 fields where the first and the
    last fields set as 'required'. In this case it is possible to trick
    decoder to return incomplete ProtobufCMessage struct with missing
    required fields by providing only one of the two fields in the
    source byte stream. This can be considered as a security issue as
    well because user's code do not expect incomplete messages with
    missing required fields out from protobuf_c_message_unpack(). Such a
    change could introduce undefined behaviour to user programs.

This patch is based on Andrei's fix and restores the exact detection of
missing required fields, but avoids doing a separate allocation for the
required fields bitmap except for messages whose descriptors define a
large number of fields. In the "typical" case where the message
descriptor has <= 128 fields we can just use a 16 byte array allocated
on the stack. (Note that the hash-based approach also used a 16 byte
stack allocated array.)

fixed gcc warnings 'integer constant is so large that it is unsigned' for large 64 bit constants (default values)

protoc may not be on the default PATH, so augment $PATH with the
executable path registered by pkg-config for the protobuf package.

additionally declare PROTOC as a precious variable, thus allowing it to
be explicitly set by the user at ./configure time.

based on a patch from Andrei Nigmatulin.

the protobuf header files may be installed in a non-standard location
and thus we need to use the CFLAGS registered for protobuf in pkg-config
in order to find them.

based on a patch from Andrei Nigmatulin.

Makefile.am: use CXXFLAGS instead of CFLAGS for protoc-c/protoc-c, t/generated_code2_cxx_generate_packed_data

these are C++ programs, not C programs, so use CXXFLAGS instead of
CFLAGS.

based on a patch from Andrei Nigmatulin.

if pkg-config is installed, the libprotobuf-c .pc file will be
installed; if pkg-config is not installed, the .pc file won't be
installed.

this behavior only applies when we're building with ./configure
--disable-protoc, since pkg-config is required in order to detect the
protobuf dependency.

this is conditional on whether the linker supports version scripts, for
which we use the gl_LD_VERSION_SCRIPT macro from the gnulib project.

on platforms without version scripts, we fall back to libtool's
-export-symbols-regex.

it's possible for the <google/protobuf/compiler/> header files to be
shipped in a separate package (e.g., debian's libprotoc-dev). check for
this at configure time rather than allowing the build process to fail.