Define SpecCompliance enum for controlling spec strictness

[telecos]

This PR is originated after #2764 and #2684 where it was spotted the need to allow controlling strictness on the decoder for accepting files which may not be fully compliant to the spec. A solution was implemented to #2764 defaulting to lenient validation for BMP (which is also the case for JPEG and PNG for example). In #2684 it was spotted the need to allow forcing strictness of validation to allow control from the caller and a solution based on a boolean parameter was proposed. This PR is proposed a common solution for codecs allowing such control (at this point BMP and JPEG).

[mstoeckl]

This PR is proposed a common solution for codecs allowing such control (at this point BMP and JPEG).

There is also HDR; it currently defaults to strict instead of lenient, but that may be worth changing:

image/src/codecs/hdr/decoder.rs

Lines 172 to 174 in 48ec3b3

	pub fn new(reader: R) -> ImageResult<Self> {
	HdrDecoder::with_strictness(reader, true)
	}

[telecos]

This PR is proposed a common solution for codecs allowing such control (at this point BMP and JPEG).

There is also HDR; it currently defaults to strict instead of lenient, but that may be worth changing:

image/src/codecs/hdr/decoder.rs

Lines 172 to 174 in 48ec3b3

	pub fn new(reader: R) -> ImageResult<Self> {
	HdrDecoder::with_strictness(reader, true)
	}

Thanks for pointing to this. I added a similar new_with_strictness ctor which receives the SpecCompliance enum as parameter. Also found that there was a "new_nostrict" and tagged it as deprecated suggesting usage of the new one.

[RunDevelopment]

I think this is a good idea.

I want to mention that this feature would also be useful for plugin decoders. E.g. the (hopefully soon to be) DDS decoder in image-extras currently uses a permissive mode to parse DDS headers. So if this PR gets merged, I think #2672 should be updated to add a method like: ImageDecoder::set_spec_compliance(&mut self, compliance: SpecCompliance) -> ImageResult<()> (mirroring the setter for limits). This would allow plugins to take advantage of this setting too.

[197g]

Thanks for the added motivation. The main concerns holding this back in the past:

• specialized to a small set of formats. I believe this was addressed by recent comments and potential use to image-extras. Adding it as an optional configuration to trait ImageDecoder should be doable as proposed.
• unclear requirements. This is not resolved but for this specific case we have a clearly defined target; and for externally registered decoders it is outside our set of responsibilities.

I definitely like the convergence on one type for this instead of separate ones for different decoders. I see one potential problem with the trait interface in hdr which interprets strict in the constructor whereas a trait method would use set_strict(&mut self) so it's too late. I'll sort this out in the PR for it.