- check malloc/calloc/realloc results in constructors, the JSON and
  OpenStep writers, the XML text-part helpers and base64 decoding, and
  return PLIST_ERR_NO_MEM instead of asserting or dereferencing NULL
- guard size calculations against overflow in the UTF-8/UTF-16BE
  conversions, ptrarray, and bytearray
- make hash_table_insert() report failure instead of silently dropping
  the entry; writers propagate PLIST_ERR_NO_MEM, and dict lookup caches
  are discarded so lookups fall back to a linear search
- don't overwrite an earlier parse error code in the XML parser, and
  report PLIST_ERR_NO_MEM when reading text content fails for lack of memory
- OpenStep parser: check node/data/string allocations and dict/array
  insertion results

Based on #323 by bg0d-droid.

Co-authored-by: bg0d-droid <81825610+bg0d-droid@users.noreply.github.com>

byte_array_grow() increased the capacity by a single page at a time, so
building large outputs (e.g. the plutil writer on a plist with heavily
shared references) caused a realloc and memcpy per page, i.e. quadratic
behavior that ran into fuzzer timeouts.

Double the capacity when growing. If the larger allocation fails, fall
back to the minimum size required before putting the array into its
failed state, so low-memory systems are not penalized by the extra
headroom. Also guard against size_t overflow in the capacity arithmetic.

byte_array_grow() assigned the result of realloc() directly to
ba->data and increased the capacity even if realloc() failed, so the
following memcpy() in byte_array_append() wrote to NULL + len.

On failure, free the old buffer and leave the byte array in a failed
state (data == NULL), which byte_array_append() already ignores. The
callers check for that state:

- the writers (bin, xml, json, openstep and the text output formats)
  return PLIST_ERR_NO_MEM instead of handing out a NULL/truncated buffer
- node_to_xml() base64-encodes <data> directly into the grown buffer,
  so it must bail out there (only guarded by assert() before)
- the OpenStep parser returns PLIST_ERR_NO_MEM for <hex data> instead of
  silently returning truncated data

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

This commit introduces constants for the different plist formats,
and adds 3 new human-readable output-only formats:
- PLIST_FORMAT_PRINT: the default human-readable format
- PLIST_FORMAT_LIMD: "libimobiledevice" format (used in ideviceinfo)
- PLIST_FORMAT_PLUTIL: plutil-style format

Also, a new set of write functions has been added:
- plist_write_to_string
- plist_write_to_stream
- plist_write_to_file

Plus a simple "dump" function:
- plist_print

See documentation for details.

Instead of letting the buffer grow by just the amount of bytes currently
transformed to base64 - which is basically line by line - we now calculate
the size of the output blob in advance and grow the buffer accordingly.
This will reduce the amount of reallocs to just one, which is especially
important for large data blobs.
While this is a general improvement for all platforms, it is on platforms
like Windows where realloc() can be REALLY slow; converting a 20mb blob to
XML can easily take up to a minute (due to the several hundred thousand
calls to realloc()). With this commit, it will be fast again.