GSS memory allocation initial cut for review

[Sam Hartman]

Hi.  One of the problems with using GSS-API mechanism plugins on
Windows is that the malloc provided by the C runtime requires that you
free allocations in the same dll as you allocate them.  (It's more
complicated than that, but if you follow that rule it works.)

This means that if you allocate a buffer in a mechanism, that
mechanism needs to release it.  That makes implementing
gss_release_buffer difficult.  In theory you could copy buffers in the
mechglue, or register pointers in the mechglue.

We're proposing an alternative. We're proposing that on a given
platform we use a well defined allocator for GSS mechglues and
mechanisms.  We don't think it is sufficient for a mechglue layer to
export an allocator for mechanisms to use. We think it will common for
multiple mechglues to be used in the same process and somewhat common
in that case for the same third-party mechanism to be loaded by
multiple mechglues.  So, we actually think we need to standardize on
an allocation strategy.
The question of whether we need a platform-global GSS allocator is a question for kitten and I'll eventually get around to bringing it up there.

However, a lot of this is MIT-specific. In particular, the code
changes to move all buffer allocations through one allocator and free
function are MIT specific. Also, our choice of allocator for the
Windows platform is MIT-specific up until the point that kitten
chooses something else.

I'd appreciate review of this first initial patch set now.

Assuming our claim about multiple mechglues is right, patches are also
required for buffer sets and oid sets.

Thanks,

--Sam