[Chore] Upgrade guide tracker for released and unreleased features

[art-alexeyenko]

• This PR follows the Contribution Guide
• Changelog updated

Description / Motivation

Track future required upgrade steps with this one simple trick (file).
Adds a file to track unreleased changes to templates and add-ons (JSS next section) and upgrade instructions for released versions. The goal is to have a detailed list of changes for an upgrade guide ready before each release.
Also modifies PR checklist. Each PR should include an entry to UPGRADING.md when applicable.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Chore

[illiakovalenko]

According to work item, our decision/idea was to create an "Upgrade guide" document per version
docs/upgrading/<version number>.md
I would prefer to avoid having a huge blanket of upgrades in a single file
It should be really easy to read and quickly check all the changes (also find previous changes if they are needed for customer), think about yourself as a customer.
Take a look at this example, you can find other examples in a network
cc @kendoce

[illiakovalenko]

@kendoce, @art-alexeyenko
Another idea, may be it might be better even, need to explore
There is a way to create a guide under wiki tab that is more appropriate than an .md file
See example

[art-alexeyenko]

@illiakovalenko the decision to make a single .md file for this is deliberate, for a few reasons:

1. Maintainability. We can realistically only provide update instructions incrementally (21.7->21.8, 21.8->22.0 etc). If we are doing .md files we can quickly get a bloated folder that is annoying to find correct files in
2. Findability. It would also be annoying for customers to switch between files in a large folder, it's much easier to do a ctrl+F to find a relevant version in a single file

Wiki is worth exploring though, thank you for the idea

[art-alexeyenko]

@illiakovalenko please check this updated structure.
It should make the docs more orderly, while not complicating the navigation too much.

I explored the wiki option. It seems wikis are hosted as a separate repo and we'd need a separate PR or push to updates them. I think wikis would be a better option with infrequent updates, but our aim here is to keep track of update guides every other PR or so. Plus, it's easier for community contributors to list the changes with current approach, if they choose to.

For easier maintenance, do you think the gitignore file in release branches should be updated to not track the docs folder? Reduce potential conflicts when cherrypicking changes and keep the guides in one location only?
CC @kendoce

[illiakovalenko]

Looks better!
I think regarding .gitignore we can exclude only unreleased.md file.
And we need to update our publish scripts to make unreleased.md file empty in dev branch, when we publish a new minor/major canary in dev branch

[illiakovalenko]

Reopened one comment, feel free to push another minor change and merge after that 👍