Add heif_items API to emscripten

[dukesook]

I would like add the heif_items.h API so JavaScript application can leverage that functionality.

I'm still trying to compile libheif to JavaScript/WASM so I can't test out the code yet, but I wanted some initial feedback on this task.

[farindk]

Sure, would be good to increase the coverage of the JS wrapper.

[farindk]

Main hurdle might be that we do not do any encoding and writing of HEIFs in JS yet. You cannot add items to existing files (yet), even in the C API.

[dukesook]

That's fine, I'm mostly interested in reading & decoding.

[dukesook]

Half the emscripten functions have the js prefix and the other half don't.
e.g.
heif_context_read_from_memory()
heif_js_check_filetype()

It would be nice if there was a more consistent naming convention, but this might be a breaking change. Any thoughts?

[farindk]

Half the emscripten functions have the js prefix and the other half don't. e.g. heif_context_read_from_memory() heif_js_check_filetype()

Yes. I think originally every function that required an explicit JS wrapper got the _js_ prefix. But I guess that this is not necessary. We can simply put the original name into the function table and reference the _js_ function from there. We could also leave the old _js_ functions in the table to avoid breaking backwards compatibility (and add a deprecation comment).

The convention could be: use the original name when the function is the equivalent of the original function, even if they required a wrapper. Functions that are JavaScript specific (e.g. heif_js_decode_image2) keep the _js_ prefix.

[farindk]

For heif_item_get_item_type() vs heif_js_item_get_item_type_string() it's a bit tricky. I would argue that working with uint32_t on the JS side is inconvenient such that we always use strings for four-cc codes. Hence, the original name heif_item_get_item_type() is ok despite the changed type.

[dukesook]

The PR now:

• Adds the heif_item.h API
• Adheres to a naming convention & deprecates functions don't follow it
• Ignores the buildjs directory
• Uses alloca() instead of malloc()