Proposed platform assumption changes

[ghudson@MIT.EDU]

I'd like to propose some changes to the platform assumptions we make
for the krb5 code base.  In short:

* Assume POSIX signal support
* Assume IPv6 support
* Assume C99 variadic macro support
* Assume threading support (POSIX or Windows)
* Assume mutex unlocking can't fail
* Assume mutex locking can't fail

Here's some longer discussion of the above and other possible changes:

* POSIX signals, IPv6, and thread support have become ubiquitous on
  platforms people are likely to build krb5 on.  We can reduce
  complexity (particularly in network code by assuming IPv6) by
  assuming these features.

* We don't have a lot of uses for variadic macros, but we do have a
  few (like the macros in k5-trace.h), and they've already crept into
  the code base a bit.  It's one of the few C99 features supported by
  MSVC.

* It's basically impossible to recover gracefully from failure to
  unlock a mutex.  In practice, I think mutex unlocking generally
  can't fail except due to programmer error (unlocking a mutex you
  don't own).

* Having to check for mutex lock failures adds a lot of failure
  handling logic which is difficult to test and probably unnecessary.
  The only practical case I'm aware of where a mutex lock can fail is
  if you try to lock a recursive mutex too many times, but the
  k5_mutex abstraction doesn't support recursive mutexes anyway (when
  we need them we build our own wrapper).

* I also considered proposing an aborting malloc wrapper.  Platforms
  generally respond to out-of-memory conditions by killing processes,
  not returning null from malloc(), and checking for malloc failures
  adds an extraordinary amount of failure handling logic to our code,
  which again is difficult to test.  However, Kerberos code is
  sometimes used in kernels or in embedded environments, and I'm
  reluctant to make a change which might prevent it from being used
  there.

* Named structure initializers appear to be a favorite C99 feature;
  we've had three separate cases in the past year of people submitting
  code using them and having to ask for it to be changed.
  Unfortunately, it's not supported in MSVC, and there's no pretty way
  of wrapping them to make it work there.  We could consider changing
  our Windows build to use mingw, but that would be a lot of work and
  might present other issues.