Add CHANGELOG.md

[mokagio]

I based this on what we are already using in release-toolkit.

After this goes through code review and eventually lands into trunk, I'll carbon-copy it in the other iOS libraries for which we want to improve our SemVer workflow.

[AliSoftware]

I wonder if we shouldn't instead use this comment to have a ready-to-copy/paste block for every time we do a new version?

Like:

Suggested change

	<!-- This is a comment, you won't see it when GitHub renders the Markdown file.
	Types of changes:
	- Breaking Changes
	- New Features
	- Bug Fixes
	- Internal Changes
	-->
	## Unreleased
	<!-- When adding a new version, use this template
	## [<version_number>](https://github.com/wordpress-mobile/WordPressKit-iOS/releases/tag/<version_number>)
	-->
	<!-- When releasing a new version:
	- Remove any entry that are empty (only having `_None._`)
	- Update the `Unreleased` header to `[<version_number>](https://github.com/wordpress-mobile/WordPressKit-iOS/releases/tag/<version_number>)`
	- Add a new `Unreleased` section for the next iteration, by copy/pasting this template:
	## Unreleased
	### Breaking Changes
	_None._
	### New Features
	_None._
	### Bug Fixes
	_None._
	### Internal Changes
	_None._
	-->
	## Unreleased

Of course in this initial version of the changelog it feels a bit strange to have the same template to copy/paste in the comment and the exact same content just below outside the comment. But as we will add entries to that section, then release new versions and add new h2 sections to this CHANGELOG over time, it would become handy to have this template for new empty section around.

Alternatively, we could automate the cleanup of _None._ sections and insertion of the new Unreleased template via some Rakefile tasks or similar… but that might be for a later iteration, as I guess for a starter we probably want to keep it simple, and iterate on automation only later 😉

[mokagio]

Yeah good point.

Let's make it as easy as possible to make a new release manually, while waiting to improve/introduce automation.

[AliSoftware]

I wondered if we should provide a template for each entry, like * <Short description of the change> [#PRNumber]. But then I thought that it will probably become obvious once we start having concrete entries in that CHANGELOG and people will naturally follow the structure of the previous entries they see so it might not be necessary after all? 🤷