Add support for ICO

[P1n3appl3]

This PR adds support for the ICO format.

ICO format complications

As mentioned in #8, ICO is a container format, which raises the question of which image dimensions should be retrieved. I agree with the comment there that the largest size is probably the most helpful to end users, and short of modifying the API (probably not a good idea) i think it's the best solution.

It's possible that it'd be even more helpful to return the size of the "highest quality" image contained, using some measure of size, bit depth, color planes, and encoding (ICOs can contain other formats such as PNGs), but due to complexity I think that it's fine to just take the largest. If it happens to be monochromatic, so be it. In practice I think you usually expect ICOs to just contain different scale versions of the same image so it doesn't end up mattering.

Partial header behavior

If the ICONDIR header specifies that there will be several image entries, but we run out of bytes before we parse them all, I think we should return the largest one found so far, rather than an error. If we were reading from a file and hit EOF, then we'd want to return an ImageError::CorruptedImage, but if reading from a partial image file with blob_size() giving back a size is preferable.

Modifying Ord for ImageSize

When writing the logic to take the largest image, I realized that ImageSize already derived Ord. While it's probably not an issue in practice (because most ICO images are squares) I think that using the area of an image would be a more natural way to order them by size. If this isn't wanted, I can revert the modified Ord/PartialOrd impls and let it take the widest rather than largest image since that's the current behavior.

[Roughsketch]

Tests pass and I've been running a fuzzer on it for about a day with no issues, so seems good to me.

I will release this as 0.10.0 sometime in the next few days.

Thanks for contributing!