Allow to configure custom ErrorMessageFactory and DifferenceCalculator

[Mackzwellz]

I'm trying to make assertion error messages helpful and human-readable in an established test framework with nested POJO comparisons (similar to #3352).
I would like to avoid making changes to existing implementation of POJO comparison (mainly, keep overridden equals with some of the fields ignored) while also reaping the benefits of AssertJ (mainly, error messages produced with usingRecursiveComparison() that pinpoint the exact difference between objects). I have a more in-depth description and examples of what I'm trying to achieve in this repo's readme.

So far, I came up with this implementation. I'm mostly happy with default behavior and output of usingRecursiveComparison(), but I would like to customize it a bit more.

Things I'm currently not happy about:

1. There is no way to specify an ErrorMessageFactory for assertion.
   In my case, I'd like to customize some aspects of it (e.g. remove full output of actual and expected at the top, and comparison strategy description at the bottom) while keeping others as-is (e.g. difference output). I had to use overridingErrorMessage(), which also causes me to essentially do the equals check twice.
   Have I had something like withErrorMessageFactory(new EMF()) or something similar that would allow me to keep calculated differences, but customize the rest of the message, this would have been a lot easier and had less compute overhead.

2. usingOverriddenEquals() throws nice output of differences out of the window, and that's understandable default behavior. But could we have the cake and eat it?
   In my case, having something like withDifferenceCalculator(new RCDC()) would allow me to keep using overridden equals and still provide some logic to calculate differences specifically for assertion error message.
   Alternatively, we could have some mechanism (e.g. an interface that caller would implement for their objects) to get only used/only ignored fields, and use that as source of truth for list of fields for recursive comparison. The added benefit would be the fact that I could also use the same list of fields in my overridden equals (whether this is a good idea is debatable). However, the more I think about it, the more I'm convinced that it's somewhat out of scope for AssertJ, and I'm trying to solve a problem in a way that it shouldn't be solved. Any input would be welcome here.

3. Is there a reason it's so hard to make a custom recursive assert (e.g. public class CustomRecursiveAssert<SELF extends CustomRecursiveAssert<SELF>> extends RecursiveComparisonAssert<SELF>)?
   I made do without it by having a minimal wrapper class around default RecursiveComparisonAssert, but I wonder if users are not expected to be able to do this, or it's just that implementation is not extensible by default (but could be in future)?

I understand that my use case might be rather niche/obscure, and it's fine if the proposed changes are not considered as something that should be available to most of AssertJ users. If that assumption is true, I'd like to get some comments about suggested course of action in my case, at the very least.

Still very much happy to use AssertJ, and thanks for your time!