Introduce schema comparison

[vil1]

This PR introduces a mechanism for comparing two schemas.

Schemas are compared asymmetrically: one is considered the "writer" and the other the "reader". The comparison builds a result that can be either:

• a Match with a (possibly empty) list of compatible transformations from writer to reader
• a Mismatch with also a list of compatibility violations

A compatible transformation is a difference between writer and reader such that message written using writer remain compatible with reader.

In a first iteration, I've decided to remain as close as possible to avro's spec in the set of accepted transformations. More might be implemented later.

[pepegar]

Added some comments. They're mostly related to naming. Apart of them, this looks awesome, thank you very much @vil1 !

[pepegar]

I would name all cases of this ADT using nouns:

[pepegar]

Suggested change

	final case class NumericWiddening[T](relativePath: Path, from: T, to: T) extends Transformation[T]
	final case class NumericWidening[T](relativePath: Path, from: T, to: T) extends Transformation[T]

[pepegar]

Suggested change

	final case class CoproductWiddening[T](relativePath: Path, coproduct: T) extends Transformation[T]
	final case class CoproductWidening[T](relativePath: Path, coproduct: T) extends Transformation[T]

[pepegar]

Suggested change

	final case class PromotedToEither[T](relativePath: Path, either: T) extends Transformation[T]
	final case class EitherPromotion[T](relativePath: Path, either: T) extends Transformation[T]

[pepegar]

Suggested change

	final case class PromotedToCoproduct[T](relativePath: Path, coproduct: T) extends Transformation[T]
	final case class CoproductPromotion[T](relativePath: Path, coproduct: T) extends Transformation[T]

[diesalbla]

Given that all the Transformation[T] classes have a relativePath field, I wonder if we can split them in two classes:

final case class At[T](relativePath: Path, transformation: Transformation[T])
sealed trait Transformation[T]
  final case class NumericWidening[T](from: T, to: T)    extends Transformation[T]
  final case class StringConversion[T](rfrom: T, to: T)   extends Transformation[T]
  final case class Addition[T](added: T)                 extends Transformation[T]
  final case class Removal[T](removed: T)                extends Transformation[T]
  final case class PromotionToOption[T]()                  extends Transformation[T]
  final case class PromotionToEither[T](either: T)       extends Transformation[T]
  final case class PromotionToCoproduct[T](coproduct: T) extends Transformation[T]
  final case class CoproductWidening[T](coproduct: T)    extends Transformation[T]

[vil1]

should be better now

[diesalbla]

In order to trim down the complexity for this case (essentially MxN cases), perhaps we could add a quick "canFit" predicate, one which would approximate the full "is compatible" case. Approximate, in this case, would mean that if canFit(p._1, p._2) is false, that implies that p._1 cannot be compatible with p._2. The benefit of course would be that canFit would only look at the top level (not recursive).

[vil1]

I think this must indeed be addressed, but should be in another PR.

Beside the approach you suggest, we should be able to avoid a whole bunch of unnecessary comparison by making the traversal monadic (hyloM) or using another scheme (maybe apo but I'm not completely sure about that).