Render rich assertion diff

[mpkorstanje]

---

I hereby agree to the terms of the JUnit Contributor License Agreement.

---

Definition of Done

• There are no TODOs left in the code
• Method preconditions are checked and documented in the method's Javadoc
• Coding conventions (e.g. for logging) have been followed
• Change is covered by automated tests including corner cases, errors, and exception handling
• Public API has Javadoc and @API annotations
• Change is documented in the User Guide and Release Notes

[mpkorstanje]

For discussion:

There are several challenges in rendering a rich diff based on the actual and expected values.

1. The string representation of actual and expected values depend on toString() implementation. For most classes this is a single line. But not consistently so.
   1.a. Exception: AssertJ does format the string representation and use multi-line formatting for collections, but only if the collections/strings are large enough.
   1.b. This could be overcome by using more complex formatting. Or using the opentest report instead for the POC.
2. While with Support accurate programatic presentation of AssertionFailedError ota4j-team/opentest4j#210 in place we can "substitute" the exception message. We don't have enough information to know if an assertion library either provided a reason, provided a null reason or didn't implement the reason yet.
3. MultipleFailuresError needs special handling too.
4. String representations might inherently not be diffable without special treatment for example Set::toString does not render elements in a legible order.
   4.a. Sorting could be an option, but elements might not be comparable.

Suggestions:

0. Wait adoption.
1. After adoption limit rich diffs to assertions on String.
2. Introduce a DiffableRepresentation object to mark string representations as diff-able.