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 :)
> majority of consumers of this are developers of some description

But not developers of WebODF, so not really interested in our internals. And perhaps also beginners. To make their life simple and to avoid confusion, I would prefer to have enough usabe info for them available already in some place outside of WebODF-internals-centric discussions.

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. Could be done as part of a dot-point, but somehow I guessed the structure would be better if there were headings for each item. We might see...

> 1000 commits in the same life as WebODF, which has 3700 commits

oh metrics... :ocean: