Inconsistently broken Decoder creation for several formats

[amyspark]

Hi,

Related to image-rs/image#2892, the supplied implementation of Read+Seek there (which constrains the file position to positive values of i64, and cannot read more than 2GB at a time) causes the Decoders for the following formats to fail with strange errors:

• OpenRaster: 0:00:00.612330300 2564 7632 WARN ImageRsTypeFind video\image\src\typefind\openraster.rs:35:gstimagers::typefind::openraster::type_find::{{closure}}: File is not OpenRaster: Format error decoding OpenRaster: i/o error

I was not able to determine why or how at first glance, but when I copy the file wholesale into memory, OpenRaster devolves into #40 suggesting that there's an underlying problem with the ZIP container reading.

[RunDevelopment]

I think this is because some decoders assume that they start reading at stream position 0. (I think I saw one in image proper making that same assumption too.)

We should probably add a test to ensure that decoders don't make that assumption.

[amyspark]

Upon further checks, it seems that for file sizes which aren't a multiple of 8k, the last read is expected to yield the remaining data instead of returning 0 (which is taken as "unexpected eof" somehow, even though it's allowed: https://doc.rust-lang.org/std/io/trait.Read.html#tymethod.read)