chore(changelog): add changelog with details about v2 release

[dancormier]

This PR adds a CHANGELOG.md which includes changes in v2.

Note
I tried to roughly stick to the format produced by Release Please. I figure this is the format we'll likely use in the future. Let me know if I need to alter the changelog formatting at all please.

[netlify]

✅ Deploy Preview for stacks ready!

Name	Link
🔨 Latest commit	4b42b9d
🔍 Latest deploy log	https://app.netlify.com/sites/stacks/deploys/652573e8b871c7000927b4b6
😎 Deploy Preview	https://deploy-preview-1514--stacks.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[giamir]

@dancormier Thanks for adding this.

I was reflecting a bit about adding this file manually like that and I started to think we should not do it until we have a tool such as release-please automatizing this process.
I am saying this because if we start to now maintain a changelog file we will need to remember to do it each time we release. We are already writing sort of a changelog manually in the Github Release and that is probably sufficient for our status quo.
Apologies for adding as an acceptance criteria to create a changelog.md (I was probably thinking about adding the changelog somewhere - the GH release being sufficient)

So I am suggesting to close this PR if you agree and wait until we integrate a tool such as release-please.

Sidenote

I was reading the documentation of release-please as part of this review. I think that would be the correct tool for us if we want to stick 100% to conventional commits for our changelog generations. I think this works particularly well for small packages, for a larger repo like ours it might be a bit trickier to fit all necessary changelog info in git commit messages. What are your thoughts on this?

I think we should consider also changesets. Changesets works similarly to release-please but does not rely on conventional commits. Instead authors need to proactively describe their changesets in yml files that then get picked up by the changesets GH action to open release PRs similarly to what release-please does.

From their docs (they are not totally wrong)

Git is a bad place to store this information, as it discourages writing detailed change descriptions - 
you want to allow people to provide as much documentation for the change as they want.

I am not advocating to use changesets over release-please. I am merely suggesting to look into it before making a decision. A downside of using changesets over release-please could be the introduction of some extra complexity (yml files, changesets cli, ...).

I believe the story for extracting axe-apca in its own repo could get an additional acceptance criteria to test changesets for releases. This could inform a potential Team ADR to pick one tool over the other one for automatic releases.
I went ahead and added the additional acceptance criteria.
Let me know if you have any concerns.