feat(jpeg): Support encoding/decoding arbitrary metadata as comments

[lukasstockner]

This is needed to port Blender's current JPEG IO code to using OIIO, but is also a useful feature to have in general.

For reading, the code tries to parse comments as colon-separated key-value pairs and sets metadata accordingly. For writing, this needs to be explicitly enabled by setting jpeg:com_attributes to 1 in order to avoid accidentally bloating files for existing applications.

Tests

I've added a small (~10KB) JPEG file containing Blender metadata and a basic test that parses it, checks that the metadata was read correctly, writes it twice (once with and once without jpeg:com_attributes), and then checks that those files are also parsed as expected. In case you're wondering why the info for "no-attribs.jpg" still contains one Blender attribute - that's because the first COM field is still put into ImageDescription just like before, so even without jpeg:com_attributes it ends up being written to the output file and recognized during parsing.

Checklist:

• [x] I have read the contribution guidelines.
• [x] I have updated the documentation, if applicable.
• [x] I have ensured that the change is tested somewhere in the testsuite (adding new test cases if necessary).
• [ ] If I added or modified a C++ API call, I have also amended the corresponding Python bindings (and if altering ImageBufAlgo functions, also exposed the new functionality as oiiotool options).
• [x] My code follows the prevailing code style of this project. If I haven't already run clang-format before submitting, I definitely will look at the CI test that runs clang-format and fix anything that it highlights as being nonconforming.

[linux-foundation-easycla[bot]]

The committers listed above are authorized under a signed CLA.

• :white_check_mark: login: lukasstockner / name: Lukas Stockner (06ad8d513deae68f0fab3f23af3383fc1f00e650, 1763e1ad67540f7f1e62394c47e38fcd55db5471, ba93c68540dbd7467c35ed4bb85fc7684159ce3a, 39c6d81653b011f7c78e21d3b25e39e1634db7bd)

[lgritz]

The Mac failures are unrelated and fixed by a different PR that has already been merged.

[lgritz]

@lukasstockner Is this ready to merge, or is there more you wanted to do at this stage?

[lukasstockner]

@lukasstockner Is this ready to merge, or is there more you wanted to do at this stage?

I still want to implement the ImageDescription logic discussed above. I didn't find time yet, but hope to do so tomorrow.

[lgritz]

@lukasstockner Just a reminder, you were going to make a minor adjustment here, and then I think we are ready to merge. You may also need to rebase on the current main and resolve some very minor conflicts that have occurred since you started this PR.

[lgritz]

Ping @lukasstockner

[lukasstockner]

So sorry for the delay here, I've finally implemented the improvement we discussed. There's still some ambiguity (e.g., Example: A tree will be parsed as a key-value pair), but now there is a setting to disable that.