In the event of a memory error, we were trying to free a null pointer
while leaking the allocation for field_expanded_alloc.

These variables aren't used outside of this for loop, so they should
be declared within it.

add switch_hashtable_insert_destructor so you can insert a pointer into a hash with a custom destructor and use it in spandsp to fix a leak on reloadxml with the tone_descriptor tables and fix a bunch of random tiny leaks etc

Prior to this commit, if anything at all went wrong in
switch_ivr_phrase_macro_event() we would generate a warning like this:

  [WARNING] switch_ivr_play_say.c:348 Macro [macro_name]: 'pattern_name' did not match any patterns

This is clearly misleading.  The natural thing to do on seeing that
message is to verify that the language files are there, and that the
pattern really does exist in that macro.  But none of that was usually
the problem.  The message would be generated if the language wasn't
found, or if the channel had gone away, for example.

With this commit, we verify that we actually tried looking for the
pattern before displaying the warning about the pattern not matching.

For years we've been generating spurious messages like:

  [WARNING] switch_ivr_play_say.c:348 Macro [voicemail_ack]: 'saved' did not match any patterns

This would happen when the caller hangs up during the playback of
certain prompts in the voicemail system where we weren't checking the
return value of vm_macro_get().  Looking closely at the log, it's
clear we were calling down into switch_ivr_phrase_macro() long after
the channel was gone.

The message above is also misleading -- switch_ivr_phrase_macro()
would have been able to find that pattern just fine, but it never
actually looked because the channel was gone.  We'll clean up that
message in a follow on commit.

If we received an event without a content-type header we were
dereferencing a null pointer leading to a seg fault.
Reported-by: Ico <ico@voip-io.org>

ESL-90 --resolve

We were actually checking this indirectly in the loop that follows,
but it's more clear to check this immediately and directly.

- fixed AEAD IV calculation for big-endian machines

This commit resolves issue #46.  The GCM mode was using the wrong master SALT length.  The master SALT should be 96 bits instead of 112 bits.  Note, GCM mode uses the legacy CTR mode for the KDF.  The legagacy CTR mode cipher implementations assume a 112 bit SALT.  Changes to the cipher abstraction layer API are required to provide the ability to specify the SALT length.  For now this commit modifies the SRTP layer to ensure the SALT is zero-appended before initializing the KDF.  This commit also provides public definitions for the GCM cipher suite master key sizes to avoid confusion for application developers.

ESL-89: --resolve add rubymod-install and add ability to use a ruby not in your path by setting RUBY env var

The relevant v8 build issues are believed to be worked out at this
point.

FS-5832  regression.... After this change the sticky completes were deleting.  This should correct it

We can't use their new mb_gets() because they call exit(3) in the
event of a read error, which isn't what we want.

ref: http://my-basic.googlecode.com/svn/trunk@57

...after dos2unix conversion.

Having an unaltered base point in tree makes future merges with
upstream much easier.

ref: http://my-basic.googlecode.com/svn/trunk@54

gets(3) is going away; it's been removed by C11, and gcc now warns on
it, breaking the build.