Read Short as u16, SignedShort as i16

[weiji14]

Previously, Short values were read incorrectly as u32 instead of u16, and SignedShort values were read incorrectly as i32 instead of i16.

This PR does the following:

• Add TiffFormatError::ShortExpected enum variant
• Correctly cast Type::SHORT as u16 values, and support casting Short to other unsigned types via the into_u32_vec and into_u64_vec methods.
• Correctly cast Type::SSHORT as i16 values

Fixes #204

[fintelia]

The hard part is still this concern:

This makes sense to fix, though the annoying part is figuring out whether anywhere else in the code is relying on the current behavior. Or whether it is likely to break any downstream users and thus might warrant additional caution

[weiji14]

The hard part is still this concern:

This makes sense to fix, though the annoying part is figuring out whether anywhere else in the code is relying on the current behavior. Or whether it is likely to break any downstream users and thus might warrant additional caution

A tiff::decoder::ifd::Value would still need to be cast into a primitive type using into_u16, into_u32 or some other method no? My impression was that the change here would mean a user who is already doing Value.into_u16() would save some memory by not going through u16 -> u32 -> u16 as before, but just u16 all the way. That said, I do agree that this would warrant a minor version bump (or whatever cargo-semver-checks suggests 😉).

[fintelia]

Cargo semver-checks doesn't capture behavior changes. If there's downstream code that assumes (perhaps via if let) that it'll get a Value::Unsigned() for something and we switch the decoder to produce Value::Short() instead, the code will stop working.

[weiji14]

Ok, what would you recommend then to mitigate against downstream breakages? Would a minor version bump to v0.10.0 (with a changelog entry that mentions this breaking change) not suffice?