protoc-c: preserve case in C enum value names (Issue #129)

there is some confusion with regard to the use of lower case letters in
enum values. take the following message definition:

    message LowerCase {
      enum CaseEnum {
        UPPER = 1;
        lower = 2;
      }
      optional CaseEnum value = 1 [default = lower];
    }

this generates the following C enum:

    typedef enum _LowerCase__CaseEnum {
      LOWER_CASE__CASE_ENUM__UPPER = 1,
      LOWER_CASE__CASE_ENUM__lower = 2
        _PROTOBUF_C_FORCE_ENUM_TO_BE_INT_SIZE(LOWER_CASE__CASE_ENUM)
    } LowerCase__CaseEnum;

note that the case of the enum value 'lower' was preserved in the C
symbol name as 'LOWER_CASE__CASE_ENUM__lower', but that the _INIT macro
references the same enum value with the (non-existent) C symbol name
'LOWER_CASE__CASE_ENUM__LOWER':

    #define LOWER_CASE__INIT \
     { PROTOBUF_C_MESSAGE_INIT (&lower_case__descriptor) \
        , 0,LOWER_CASE__CASE_ENUM__LOWER }

additionally, the ProtobufCEnumValue array generated also refers to the
same enum value with the (non-existent) upper cased version:

    const ProtobufCEnumValue lower_case__case_enum__enum_values_by_number[2] =
    {
      { "UPPER", "LOWER_CASE__CASE_ENUM__UPPER", 1 },
      { "lower", "LOWER_CASE__CASE_ENUM__LOWER", 2 },
    };

we should preserve the existing behavior of copying the case from the
enum values in the message definition and fix up the places where the
(non-existent) upper case version is used, rather than changing the enum
definition itself to match the case used in the _INIT macro and
enum_values_by_number array, because it's possible that there might be
existing working code that uses enum values with lower case letters that
would be affected by such a change.

incidentally, google's C++ protobuf implementation preserves case in
enum values. protoc --cpp_out generates the following enum declaration
for the message descriptor above:

    enum LowerCase_CaseEnum {
      LowerCase_CaseEnum_UPPER = 1,
      LowerCase_CaseEnum_lower = 2
    };
t/: add test case for Issue #129 from Oleg Efimov
configure.ac: check for a libprotoc header file

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.
.gitignore: anchor Makefile and Makefile.in at the top of the tree
LICENSE: update the copyright notice
README.md: mention the <google/protobuf-c/protobuf-c.h> compat symlink
README.md: add note about semantic versioning
protobuf-c/: update copyright notices
version the libprotobuf-c symbols on compatible linkers (Issue #116)

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.
configure.ac: make pkg-config optional when building with --disable-protoc

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.
ChangeLog: update
ChangeLog: more updates
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.
configure.ac: use $protobuf_CFLAGS to find protobuf header files

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.
configure.ac: search the pkg-config exec_prefix for the protobuf compiler

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.
fixed gcc warnings 'integer constant is so large that it is unsigned' for large 64 bit constants (default values)