Allow naming formats registered via hooks

[Shnatsel]

PR #2372 added decoding hooks, so a third-party format implementation can be registered as a plugin and work through all the usual facilities in an abstract way.

It also added a Format enum that lets image refer to these plugin formats:

https://github.com/image-rs/image/blob/1ed88e44e9acf5f08ac5236deda9b1ebeedc6054/src/io/image_reader_type.rs#L14-L18

However, that enum is private.

In wondermagick I keep running into the need to name formats, including plugin formats. For example, the input can be prefixed with a format modifier, e.g. webp:some_file, that specifies what format "some_file" should be treated as. There's Decoder::set_format that allows precisely that, but it accepts ImageFormat enum that can only represents built-in formats, not the ones registered via plugins.

Draft

I think the best way is going to be to just another variant to ImageFormat to represent third-party plugins, in the same way as the private Format does today, and retire the private Format afterwards.

[fintelia]

I'd be more inclined to add a ImageReader::set_file_extension method (potentially with a different name) that set the format via file extension, since that's what the Format::Extension variant refers to, not that the format will necessarily be decoded via a plugin.

[197g]

While I also see some use for set_file_extension as an interface, the format type need seems more immediate. There are a bunch of methods on the builtin ImageFormat which could be transferred to such an (opaque) type as well. Also, set_file_extension is unclear when the link to hooks is not immediate. If I pass jpeg, I might expect to get matched with the builtin Jpeg decoder as well? Afterall, a much more intuitive way to use such a name may be closely emulating the path-based open with a non-File input. But relaxing the disjunction between hooks and ImageFormat is hard to realize without a type that implements a good PartialEq and aligns with expectations somehow, at least in a testable sense.

[JWill392]

I'm encountering a related issue; it seems impossible to tell if ImageReader::with_guessed_format succeeded with a third party format. ImageReader::format() returns Option<ImageFormat> enum rather than private Format enum, and it flattens even successful third party extension formats to None.

I was hoping to quickly read through a bunch of files and determine which are parseable images without decoding them, but I don't see a way to do that with third-party integrations.