Add ChangeLog.md

Thinking about the release of WebODF 0.5.1 ' one finds that a changelog would be useful, as possible users might want to know if upgrading their copy of WebODF/Wodo.TextEditor is worth the effort.
To compile the changelog, the release manager has to go through all the commits since the last release and see what was done. Which is not a joyful thing, as commit messages are not often perfectly written and especially with older commits or one where the person was not involved it is unclear what actually changed. Also are commit messages usually done with other project developers in mind. Where a changelog is instead interesting to the users of the products. They are interested if there are e.g. risks, new/lost features, fixes and breaking changes.

So I propose to maintain a file next to the commit messages, where we add all changes phrased in a way that product users get an idea about the change (perhaps even with hints how to use new features or adapt their code to API breakages). So in the future each PR would usually also have a commit/changes to this file.

Agreed to have that?

Please also check the actual content, as I would like to use exactly this text for the 0.5.1 release announcement ;)

' As wanted/needed to release ViewerJS, because that one is created mainly from code in the WebODF repo still and a clear version number for its WebODF plugin would be nice, which is taken from the WebODF version. But also exercising frequent releasing does not hurt :)
One thing to keep in mind is that majority of consumers of this are developers of some description... otherwise why are they reading WebODF release notes if not to update their own program? :-)

I wouldn't suggest other files as it is more maintenance burden. Links back to the bug tracker here on github would be best suited. As you said, these can't be too hard to maintain or they won't be kept up-to-date.

The langohr project is much quieter project than WebODF (~1000 commits in the same life as WebODF, which has 3700 commits!), which explains somewhat why the changelogs are readable in this format.

I think that single-sentence reports that provide the end user impact of a particular fix are probably sufficient for the interests of the readers.