Implement partial jpx-write support and add new `opj_merge` utility

[dgarciabriseno]

In this PR I've added partial support for writing jpx files.

What's New

• opj_merge utility
• jpx compression codec (OPJ_CODEC_JPX)

Public API

I've added a new jpx codec which is created when you call opj_create_compress(OPJ_CODEC_JPX).

From there the usual interface of opj_encoder_set_extra_options, opj_setup_encoder, opj_start_compress, opj_end_compress, should all be called to complete the process.

For this codec, opj_encoder_set_extra_options is used to specify the list of files that will be merged into the jpx file.

Internal Changes

• Added jpx.c and jpx.h
• Made some static jp2.c functions non-static so they could be called from jpx.c. Mainly box writing functions.

Overview of What I've Done

I manage an application which relies on kdu_merge -link. The opj_merge utility I've written has similar behavior as the kdu_merge command. What this merge does, is it creates a jpeg2000 file with only boxes, and no codestreams. The boxes included are:

1. signature box
2. file type box -> special note that for jpx, the brand is "jpx " and the compatibility list (cl) includes ["jpx ", "jp2 ", "jpxb"].
3. A reader requirements box which specifies the features supported in the jpx. I put values "(2) Contains multiple composition layers" and "(15) Fragmented codestream where not all fragments are within the file but all are in locally accessible files" See Table M.14 in ISO/IEC 15444-2 for more details on the values available for this box.
4. A jp2h header which is a shared header among all images. More on this below.
5. A series of fragment table boxes. 5.1 Each fragment table contains a fragment list box 5.2 Each fragment list box points to a j2k codestream in the jp2 files being merged. Specifically the codestream's file offset and length.
6. A series of association tables 6.1 The association table uses a Number List Box to designate which jp2 the association is being made for 6.2 Any XML boxes in the source jp2s are embedded here. With an association table made for each xml box. If there's no xml box in the source jp2, then no association is added to the jpx.
7. A Data Reference Box. This is where the actual local paths to the jp2 files are stored.

Partial Support

• The jpx file type allows for embedding the codestreams into the jpx file itself. I did not implement this, but it could be added at a later time.
• Technically the codestreams embedded or referenced in the jpx can have their own headers also embedded in the jpx. I did not implement this. Instead, the one jp2 header in the jpx is used to describe all the embedded files, and it comes from the very first jp2 file being embedded. I make this restriction clear in the help message of opj_merge.

Next Steps / Things I need help with

• It would be good to have some tests for this. To test this manually, I wrote a "dump" utility which prints out all the box information from the given jpeg2000 file. And I compared the output of opj_merge with the output of kdu_merge. It's not one-to-one since kdu_merge adds in some extra things that I didn't think needed to be there according to the standard. See jp2dump
• Building on windows. I'm not sure how to test the windows build. I have a windows laptop, but I'm able to compile it there, so I don't know why the windows build is failing in CI. Is there a way to view the compilation logs?
• Fix warnings