MultipleFailuresError builds its own error message, caller can just specify the message heading

[jdlib]

I want to comment on the design decision to let MultipleFailuresError build the final error message (the caller may only supply a heading), which in my eyes is very unfortunate. This topic has been touched slightly in issue #46.

I'm not aware of any general purpose Throwable implementation which changes the error message passed by the caller. With regard to assertion errors there are at least two main places where the assertion error message is used:

1. in an error report (e.g. generated from the junit ant task during an automated build).
2. in an IDE during development when a developer tests the code (e.g. runs JUnit in Eclipse).

In scenario 1) the assertion library knows best how the message of a soft/multi assertion message should look like
in order to fit the style of it's single assertion messages. For example take the beautiful multi-line formatting which is done by https://strikt.io/ (scroll down to "Soft assertions") and think how this message would be butchered by MultipleFailuresError. Of course the report engine should also recognize MultipleFailuresError and print detail information by evaluating getFailures().

In scenario b) good IDE support would present the error message + stacktrace as first level and in the second level recognize specific AssertionError classes and give the developer access to the information stored in the error object.
For instance when encountering AssertionFailedErrors Eclipse presents a dialog which compares expected and actual value stored in the error. Likewise IDE support for MultipleFailuresError should evaluate getFailures() and present the list
to the developer, and not rely on the message format of MultipleFailuresError.

So in both cases I don't see a need for the formatting applied by MultipleFailuresError except as a courtesy for test libraries which don't want provide an own summary message of the contained failures on their own.

Since the actual implementation is already out in the wild, I suggest to add another constructor

public MultipleFailuresError(String heading, List<? extends Throwable> failures, boolean autoFormat)

which allows the caller to decide if she wants to apply the current automatic message format (autoFormat=true) or leave the given message unchanged (autoFormat=false).