Override clone_from implementations for a few types

[a1phyr]

I license past and future contributions under the dual MIT/Apache-2.0 license,
allowing licensees to choose either at their option.

[fintelia]

How common is manually implementing clone_from? I don't think I've seen it done in other crates

[HeroicKatora]

It's odd that derive() does not do it, but it obviously has the potential to save an allocation. Not quite as intricate as std::vec::Vec on the dynamic image but effective.

[fintelia]

This would avoid the allocation but potentially "leak" memory if the image started out substantially larger than the new size. (Technically not a leak because the memory would still remain referenced but inaccessible.) Though perhaps that's well known behavior and folks using the method would expect that?

[kornelski]

I think it's fine that clone_from keeps potentially large allocations. It's opt-in, and its purpose is to reuse allocations.

[fintelia]

This match arm should be avoided. The enum is marked non-exhaustive, but within this crate we can still match exhaustively on it

[a1phyr]

I am not sure of what you want here. Something like this ?

match (self, source) {
    (Self::ImageRgb8(p1), Self::ImageRgb8(p2)) => p1.clone_from(p2),
    (Self::ImageRgba8(p1), Self::ImageRgba8(p2)) => p1.clone_from(p2),
    // other formats...

    (this, Self::ImageRgb8(p)) => *this = Self::ImageRgb8(p.clone()),
    (this, Self::ImageRgba8(p)) => this = Self::ImageRgba8(p.clone()),
    // other formats...
}

[fintelia]

Sorry, I didn't read closely. It's fine as is