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.