Cleaner Debug output for ImageBuffer

[RunDevelopment]

resolves #1613

I spend some time making the debug output for ImageBuffer easier to read, but probably went a bit too far...

assert_eq!(
    format!("{:?}", GrayImage::new(100, 100)),
    "ImageBuffer<Luma<u8>>(100x100, sRGB)"
);

If you want me to dial the custom debug back a little, I think I could use the standard debug_struct builder to make something like this:

ImageBuffer {
    width: 100,
    height: 100,
    pixel_type: Rgb<u8>,
    color: sRGB,
}

I don't mind either way, so just tell me what you think would be best.

[197g]

I think less custom structure would be better. I don't see much reason to deviate from consistency here but the type_name approach for the debug_struct name's parameter is pretty good for readability. I'd use that.

ImageBuffer::<_, Rgb<u8>> {
    width: 100,
    height: 100,
    color: "sRGB",
}

On the fancier side I'm pondering if a fixed-size grayscale thumbnail could acehive an overview of the contents without the dump that is data in the current derive.

[fintelia]

Maybe also have a data: [1, 2, 3, 4, 5, ...], field? Enough to show the actual values of a few pixels but not overwhelm the output

[RunDevelopment]

Okay, it's now this:

ImageBuffer::<Luma<u8>, _> {
    width: 16,
    height: 16,
    color: "sRGB",
}

Unfortunately, I don't think data: [1, 2, 3, 4, 5, ...] will be possible. The only thing known about that container is that it's Debug and we don't have specialization yet. So we can't even iterate the container. The only possible solution given the current constraints is to debug print the container into a separate buffer, see if it looks like an array/vec, and then truncate it after N characters (or somewhere around a , for nicer results). Suuuper hacky, but it would probably work for common container types.

[RunDevelopment]

This could be done without an allocation in format!. Like this:

f.write_str("ImageBuffer::<")?;
f.write_str(pixel)?;
f.write_str(", _>")?;
f.debug_struct("").field(...).and_so_on

However, this relies on the fact that f.debug_struct(str) will immediately print the struct name without any additional formatting logic (like e.g. padding spaces, etc). I'm not sure if we're allowed to make this assumption.

Please tell me what you think we should do.