Allow "manually merged" changes by adding a "mergedChanges" field

When doing the final release notes of a version, you can have:

• a change done in M1 which introduces a feature and then
• in M2 (or even in final) you can have another change that improves the previously introduced feature.

When generating the final version release notes it looks confusing to see both changes since, for the end user, you are just introducing the feature, so there is no point in talking about an improvement that you have done to it.

One idea would be to add a new change, for the final version, that specifies a list of changeIDs that it "merges" (or overwrites). In this change you would manually merge the multiple changes into a single one that consistently describes the new feature and all its improvements, hiding the multiple iterations. Every query that will display a (e.g. final) version should ignore all the changes that are marked as "merged" by another change and display that "merging" change instead.

(Note that it could also be done at the macro call level, i.e. an "ignored" parameter, but this would mean that everybody should know about that list of ignored changes when computing a report).