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 :)
> But not developers of WebODF, so not really interested in our internals... I would prefer to have enough usabe info for them available already in some place outside of WebODF-internals-centric discussions.

I agree with this. The mentioned fixes don't need a complete explanation of every part, as long as we ensure bugs linked from the changelog are well maintained and complete.

> What the current sample does not yet cover are changes of the API, where the users would need to get a simple note how to adapt their code

These API changes should be definitely have longer explanations. Hopefully, they are also far less frequent than bug fixes, so less of a maintenance burden :-)