Refactor Images handling in API

[artursmet]

Now we have separated types for ProductImage and a standalone Image. This situation is caused by a need for storing more information for product images, like their reference to a particular variant and so on.

I recommend to change approach a bit - let's create an independent model for Image and replace all standalone versatileImageField fields with a OneToOneField which will refer to Image instance.

Above approach will allow us to unify all image endpoints in the API, also it may create a way to replace underlying thumbnailing library easier than now.

By the way of the refactoring we may also introduce more fields in the Image type, for example:

query {
  product(id: foo) {
    images {
      url(size: 100),
      width,
      height
    }
  }
}

Having extra fields for width and height will allow better integration with some native SDKs like Android, where exact image dimensions are required before rendering it. Size used in parameter is only one dimension - the backend decides which thumbnail will fit the best for the queried size.

Definition of done:

• Create a model for Image
• Replace all standalone versatileImageField fields with a relation to Image
• Provide data migration mechanism
• Refactor all API endpoints to follow new approach (products, collection, category etc)

[maarcingebala]

We've unified the API a bit with PR #3429, namely, now all images are either of Image or ProductImage type. Before that PR, there were e.g. thumbnailUrl: String fields. Fields like background_image in Category or Collection type would still need to be refactored to model instances, but I'm still not convinced that this is the best approach.

[maarcingebala]

Closing this since image types have been sorted out and use a common Image type.