[WIP] add support for iloc construction method 2

[bradh]

The iloc box, as described in ISO/IEC 14496-12:2022 Section 8.11.3, has a few variations.

Currently we support construction_method values of 0 (where the item content is in the mdat box), and 1 (where the item content is in the idat box). Version 0 of the box definition is equivalent to method 0.

There is also method 2, which is an indirection to the dref child boxes. Typically its a url box.

An indicative file structure might be:

Box: meta -----
size: 358   (header size: 12)
| Box: hdlr -----
... 
| Box: pitm -----
... 
| Box: dinf -----
| size: 59   (header size: 8)
| | Box: dref -----
| | size: 51   (header size: 12)
| | | Box: url  -----
| | | size: 35   (header size: 12)
| | | location: rgb_component_data.bin
| 
| Box: iinf -----
... 
| Box: iloc -----
| size: 40   (header size: 12)
| item ID: 10
|   construction method: 2
|   data_reference_index: 1
|   base_offset: 0
|   extents: 0,27648 

The reason for wanting this is to "wrap" existing files (e.g. TIFF, JPEG) with a HEIF header so I can add metadata, without needing to duplicate the content that would otherwise go into the mdat box.

There are a few combinations that this doesn't handle:

• the moof case
• data references types of urn , snim and imdt
• data references to files that are not local (e.g. where the data is on the other end of HTTP(S))

I have a plan to fix the last one (maybe using cpr - https://github.com/libcpr/cpr).

However there are a couple of issues:

• where the location is relative to the HEIF parent file (e.g. both are in ~/some/path/whatever/, and you refer to ~/some/path/whatever/parent.heif and it looks in the current directory for child_data.bin rather than in ~/some/path/whatever/child_data.bin)
• a potential file-traversal attack where if the user can upload files to a server, you can extract content from arbitrary files on the server. Not such a risk with HEIC, where its unlikely to decode, but with uncompressed codec you can get the raw content.

I would appreciate suggestions on both.

For the security issue, I've considered combinations of:

• disabled by default (i.e. needs to be explicitly turned on with a function call)
• a callback filter function that the user needs to register to validate access
• only allowing local files (i.e. deny access if the file has a path component)