AVRO-4305: [c] Make st_insert() OOM-safe

[iemejia]

What changes were proposed in this pull request?

The vendored st hash table used by the C SDK (lang/c/src/st.c) allocated table entries via avro_new() inside the ADD_DIRECT macro (used by st_insert() and st_add_direct()) without checking for a NULL return:

entry = (st_table_entry *) avro_new(st_table_entry);
entry->hash = hash_val;   /* NULL-dereference on allocation failure */

On allocation failure this dereferenced NULL and crashed rather than reporting an error, so map decoding — and every other st user — was not OOM-safe on that path. rehash(), which runs inside ADD_DIRECT, had the same problem with the Calloc() of its new bin array.

Noted during review of AVRO-4293 (bounded allocation when decoding length-prefixed values/collections); that PR fixed the map.c side but deliberately left this shared-code change out of scope.

How was this patch fixed?

• ADD_DIRECT now receives a pre-allocated entry. st_insert() allocates it, returns -1 on failure and leaves the table unchanged (0 = inserted, 1 = updated, as before). st_add_direct() (which returns void) becomes a no-op on allocation failure instead of crashing.
• rehash() skips the rehash and keeps the existing bins when the new bin array cannot be allocated — the table stays correct, only denser.
• The only caller that inspects the return value (save_named_schemas in schema.c) already treats any non-zero as an error, so the new -1 propagates correctly. All other callers ignore the return value and simply observe an unchanged table.

st_insert's contract is documented in st.h.

How was this patch tested?

New test_avro_4305 installs a failing allocator and verifies that:

• st_insert() returns -1 on OOM without crashing and leaves the table unchanged;
• a subsequent insert (memory available again) still succeeds and is retrievable.

Verified the test segfaults without the fix (SIGSEGV) and passes with it. Full C suite: 54/54 tests pass, including the valgrind memcheck_test_avro_4305 variant (no leaks).