Proposal: move to CHANGELOG-based release process

[baronfel]

This simplifies the build script with the following changes:

• move to Ionide.KeepAChangelog + migrate old release notes to changelog
• purge a lot of changelog-related code from build.fsx, now we only need it for some copy/paste archive folder management
• move creation of the github release + package push to the github actions release pipeline
  • these are now pretty simple scripts that are still easily runnable locally, just copy + paste the exact command
• remove no longer used targets from build.fsx, the primary custom stuff we do now is a) fsliblog namespacing, and b) tool package munging
• update paket/FAKE to .net 6 versions
• update to .net 6 SDK (but not TFM)

[baronfel]

@Krzysztof-Cieslak any thoughts or concerns here? the flow would be:

• push tag from local
• ???
• profit

though I could see making a FAKE task to put some safety around the tag (making sure the changelog version doesn't already exist as a tag, etc)

[baronfel]

I made a FAKE target called "Promote" that automates promoting the changelog's Unreleased segment to a new version, with some logic around what that version should be. it then commits the changelog and makes the matching tag.

[baronfel]

I'm pretty happy with this, and it's in line with things that @Krzysztof-Cieslak and I have talked about in the past, so I'm going to merge it.

[baronfel]

successfully released 0.50.0 using this method (after a tiny snafu with an expired nuget key) and it all worked great!