Use the "union" merge driver for changelogs

[neilmayhew]

Description

Avoid merge conflicts in changelog files by setting a custom merge driver for them in .gitattributes.

The union driver is built into git so there's no need to add any settings to .git/config.

Unfortunately, the changes from the merged or rebased branch are inserted below the changes from the main branch, but that seems like an acceptable price to pay for a simple configuration that doesn't involve any per-developer setup.

Checklist

• Commits in meaningful sequence and with useful messages.
• Tests added or updated when needed.
• CHANGELOG.md files updated for packages with externally visible changes.
  NOTE: New section is never added with the code changes. (See RELEASING.md).
• Versions updated in .cabal and CHANGELOG.md files when necessary, according to the
  versioning process.
• Version bounds in .cabal files updated when necessary.
  NOTE: If bounds change in a cabal file, that package itself must have a version increase. (See RELEASING.md).
• Code formatted (use scripts/fourmolize.sh).
• Cabal files formatted (use scripts/cabal-format.sh).
• CDDL files are up to date (use scripts/gen-cddl.sh)
• hie.yaml updated (use scripts/gen-hie.sh).
• Self-reviewed the diff.

[teodanciu]

I assume this will result in fewer merge conflicts, nice!
Are there other implications? If we do get merge conflicts, is there anything that we should be aware of, that we need to do different compared to what we've been doing so far?

[neilmayhew]

Are there other implications?

It's possible the merged result could have the lines in a strange order, although my experiments so far haven't shown any problems other than the one I mentioned in the description.

If we do get merge conflicts, is there anything that we should be aware of, that we need to do different compared to what we've been doing so far?

I don't think conflicts happen at all with this driver, but we should check the merge result carefully, at least until we have more experience with using this.

[lehins]

We should watch out carefully in the near future whether we can spot any issues with this strategy.
If it does work out fine, then it will be indeed a very nice improvement in our workflow, since chnagelogs is the most common source of git conflicts