WICKET-6823: Add a container to AbstractTransformerBehavior to support multiple instances per component.

[ams-tschoening]

The current implementation of AbstractTransformerBehavior replaces responses and doesn't properly take into account use cases in which multiple instances doing the same are assigned to the same component. This adds a container for those use cases to combine all those transformers into one dealing with replacing the responses instead. While that container needs to be used explicitly, it's the easiest implementation to workaround the current limitations.

The container is embedded into AbstractTransformerBehavior, because it's small overall, can easily be spotted this way by users and I wasn't too sure about a good alternative name anyway. There would be many possibilities like [Abstract]TransformerBehaviors, [Abstract]TransformerBehavior[Container|Multi], MultiAbstractTransformerBehavior etc..

This PR is based on wicket-8.x instead of master, because that is what I'm using currently and the only thing I'm able to test and build right now.

[martin-g]

This Javadoc is obsolete with the improvement below, no ?

[ams-tschoening]

I disagree, AbstractTransformerBehavior itself keeps the limitation and especially existing users should be made aware. The container is only one possible workaround/solution, a different implementation of AbstractTransformerBehavior itself would be another one. With that the sentence could be removed, but with the container only the sentence still applies.

[martin-g]

You can just say "If you need to apply several transformations on the same component then use {@linkplain AbstractTransformerBehavior.Multi}".
I see no need to write 20 lines as Javadoc explaining history.

[ams-tschoening]

Those 20 lines of history are exactly what I regularly miss when running into trouble with Wicket, because without them there's no basic understanding of why things are the way they are. When running into this problem, I needed to look at the entire GIT-history just to find no reason for the current implementation, no clue on how things were supposed to work, for a workaround fitting the existing design etc.

The docs often lack important context from my experience, so I'm trying to add one here.

[martin-g]

This javadoc should really be a comment in the PR, not Javadoc.

[ams-tschoening]

As someone who ran into that problem, I prefer having such details in the file to get a basic understanding of problems like these without looking at source history, JIRA etc. I regularly miss such details from Wicket's docs and rephrased things to not sound like a commit message too much anymore.