Fix/1144 webp support

[benlk]

Description of the Change

This PR:

• adds WebP support to Distributor, for parity with WordPress 5.8
• adds HEIC support to Distributor, for parity with WordPress 6.5
• adds AVIF support to Distributor, for parity with WordPress 6.7
• adds tests:
  • WebP
  • HEIC
  • AVIF

Closes #810

How to test the Change

Upload test AVIF, HEIC, and WebP files to a Distributor source site. Ensure taht they are synchronized to a downstream Distributor site.

Changelog Entry

Added - Support for WebP, paralleling WordPress 5.8
Added - Support for HEIC, paralleling WordPress 6.5
Added - Support for AVIF, paralleling WordPress 6.7

Credits

Props @username, @username2, ...

Checklist:

• I agree to follow this project's Code of Conduct.
• I have updated the documentation accordingly.
• I have added Critical Flows, Test Cases, and/or End-to-End Tests to cover my change.
• All tests pass:
  • existing
  • new

[benlk]

Before this PR is merged, we should:

• add tests covering support for WebP, HEIC, and AVIF — There are specific image tests in https://github.com/10up/distributor/blob/develop/tests/php/DistributorPostTest.php but it's not clear to me where the example images come from. The domain names given are fictional or reserved, and the images referenced are not included in this plugin's filesystem. Can support be added simply with mock data in the test case, or do the files need to also exist somewhere?
• add a test covering a fictional image type, to ensure that we reject disallowed media types
• discuss how to handle differences in support between Distributor instances running on different versions of WordPress — Should the receiver communicate to the sender which MIME types and other supported things are allowed? Or is it entirely upon the receiving Distributor instance to filter out that which it does not support?

[peterwilsoncc]

Can support be added simply with mock data in the test case, or do the files need to also exist somewhere?

Yes, tests can be added by mocking the image names. As the tests use https://github.com/10up/wp_mock/ the files don't need to exist in the repo.

This should work for the fictional file type too.

Should the receiver communicate to the sender which MIME types and other supported things are allowed

As some of the supported media types depend on the version of underlying libraries installed (GD, ImageMagick) then I think it would be good for the pushing instance to know what the receiving instance supports.

There's a few REST API endpoints that Distributor registers that the system could make use of. I think we'd only want to make the data available if the user is logged in to the endpoint but we'd need to check for the data during a push, which I don't think is something that's done at the moment.

Maybe add the data to check_post_types_permissions for logged in users and if the data isn't recorded in the meta data prior to pushing, then we can recheck the remote end point.