Add Extract/Clone apis for manipulating deconstructing images from from

[tocsoft]

Prerequisites

• I have written a descriptive pull-request title
• I have verified that there are no overlapping pull-requests open
• I have verified that I am following matches the existing coding patterns and practice as demonstrated in the repository. These follow strict Stylecop rules 👮.
• I have provided test coverage for my change (where applicable)

Description

This adds the new APIs to Image<TPixel> for cloning and extracting frames from an image.

New APIs

• Image<TPixel>.Clone(int frameIndex)
• Image<TPixel>.CloneAs<TPixel2>(int frameIndex)
• Image<TPixel>.Extract(int frameIndex)

TODO

• Add Tests
• Resolve API location
  should these APIs be members of Image<T> of ImageFrameCollection?
  i.e. do you call image.Clone(index) or image.Frames.CloneFrame(index)
• Resolve API names
  should the apis have the Frame postfix? I feel this depended on if the API lives on the frames collection or the image

resolves #340

[JimBobSquarePants]

The Frame suffix seems nice and explicit to me but I don't think that the APIs should live in the ImageFrameCollection. (Don't ask me why it just doesn't feel right)

[antonfirsov]

@JimBobSquarePants I think you have this feeling because all of them are returning an Image<T> instance. This makes them more bound to Image<T> than ImageFrameCollection<T> where everything operates on frame instances only.

[JimBobSquarePants]

@antonfirsov Yeah, that describes it well.

[antonfirsov]

@tocsoft All LGTM. Like that we manage the lifecycle of frames through our API now, preserving valid state for Image<T>.

We probably need a gif manipulator example, because the behavior of some functions (eg. AddFrame(otherFrame)) is not trivial now.

[JimBobSquarePants]

Very happy with this. It's come together very well!