protobuf-c: remove UNALIGNED_ALLOC, DO_UNALIGNED_ALLOC macros
spelling: "prefered" -> "preferred"
protobuf-c: remove tmp_alloc and max_alloca fields of ProtobufCAllocator

i'm confused as to why these fields exist, since the typical
implementation of a "temporary alloc" would be something like alloca(),
and alloca() is usually just inlined code that adjusts the stack
pointer, which is not a function whose address could be taken.

this breaks the API/ABI and will require a note in the ChangeLog.

possibly we could revisit the idea of "temporary allocations" by using
C99 variable length arrays. this would have the advantage of being
standardized, unlike alloca().
protobuf-c: remove alloc_failed_warning and protobuf_c_out_of_memory

in general, libraries shouldn't be responsible for terminating the
program if memory allocation fails. if we need to allocate memory and
can't, we should be returning a failure indicator, not providing a
strange interface to the user for receiving a callback in the event of
such an error.

also in general, libraries should never write to stdout or stderr.

this breaks the API/ABI and will require a note in the ChangeLog.
protobuf-c: replace DO_ALLOC, FREE, system_alloc, system_free with inline memory allocation functions

this reworks memory allocation throughout the support library.

the old DO_ALLOC macro had several problems:

  1) only by reading the macro implementation is it possible to tell
  what actually occurs. consider:

        DO_ALLOC(x, ...);

  vs.:

        x = do_alloc(...);

  only in the latter is it clear that x is being assigned to.

  2) it looks like a typical macro/function call, except it alters the
  control flow, usually by return'ing or executing a goto in the
  enclosing function. this type of anti-pattern is explicitly called out
  in the linux kernel coding style.

  3) in one instance, setting the destination pointer to NULL is
  actually a *success* return. in parse_required_member(), when parsing
  a PROTOBUF_C_TYPE_BYTES wire field, it is possible that the field is
  present but of zero length, in which case memory shouldn't be
  allocated and nothing should actually be copied. this is not apparent
  from reading:

        DO_ALLOC(bd->data, allocator, len - pref_len, return 0);
        memcpy(bd->data, data + pref_len, len - pref_len);

  instead, make this behavior explicit:

        if (len - pref_len > 0) {
                bd->data = do_alloc(allocator, len - pref_len);
                if (bd->data == NULL)
                        return 0;
                memcpy(bd->data, data + pref_len, len - pref_len);
        }

  this is much more readable and makes it possible to write a
  replacement for DO_ALLOC which returns NULL on failures.

this changes the protobuf_c_default_allocator to contain only NULL
values; if a replacement function pointer is not present (non-NULL) in
this struct, the default malloc/free implementations are used. this
makes it impossible to call the default allocator functions directly and
represents an API/ABI break, which required a fix to the
PROTOBUF_C_BUFFER_SIMPLE_CLEAR macro.

despite turning one-line allocations in the simple case:

	DO_ALLOC(rv, allocator, desc->sizeof_message, return NULL);

into three-line statements like:

	rv = do_alloc(allocator, desc->sizeof_message);
	if (!rv)
		return (NULL);

this changeset actually *reduces* the total number of lines in the
support library.
configure.ac: remove the AC_CHECK_HEADERS checks

some of these headers aren't used in the protobuf-c code base any more,
and in any case the results of these checks (the HAVE_*_H defines in
config.h) are not actually used anywhere and the absence of any of these
headers doesn't cause configure to fail, so just delete these useless
checks.
build system: add back the --disable-protoc option to configure
Makefile.am: set up a compatibility symlink for include paths that use <google/protobuf-c>

it might be premature to remove the <google/> prefix from the include
path. set up a compatibility symlink so that old code continues to
compile.
protobuf-c: add some whitespace to TRUE, FALSE defines
protobuf-c: make it a bit harder to generate output to stdio

libraries should never generate output on their own to stdout/stderr.
remove the PRINT_UNPACK_ERRORS macro and rename UNPACK_ERROR to
PROTOBUF_C_UNPACK_ERROR.

the error strings are left in but compiled out by default. they could
theoretically be re-enabled for a debugging session by changing the
PROTOBUF_C_UNPACK_ERROR macro to something like:

	#define PROTOBUF_C_UNPACK_ERROR(...) do { fprintf(stderr, __VA_ARGS__); fputc('\n', stderr); } while (0)
protobuf-c: remove PROTOBUF_C_PLEASE_INCLUDE_CTYPE, ProtobufC_CType

i'm not quite sure what this thing is used for or how useful it could
possibly be. it's not used anywhere in protobuf-c or protobuf-c-rpc, and
it wasn't in protobuf-c 0.14 or earlier. just delete it; if anything
actually needs this kind of logic, it's easy enough to replicate it.
remove protobuf-c-private.h

there's not much point to having the "private" definitions split out
into a separate header file. they're still in the namespace and there's
nothing that can be done to prevent "unauthorized" uses. just integrate
the definitions into the main header file but put them in the bottom and
note that they're "private".

this makes it very slightly easier to copy the protobuf-c support
library into another project wholesale, since one less file is required.
protobuf-c: just use <stdint.h>

according to microsoft's platform evangelist, "we recommend that you
consider using a different compiler such as Intel or gcc" if you need a
conforming C compiler. since there's already a project that maintains
the stdint.h / inttypes.h headers for microsoft compilers
(https://code.google.com/p/msinttypes/) there's not much point in
maintaining this ourselves.
protobuf-c: update #include comments

in particular we no longer use abort().
protobuf-c/libprotobuf-c.sym: new

use a linker script rather than relying on libtool's
-export-symbols-regex. this lets us start versioning the library's
exported symbols.