feat: improve ergonomics of self-update

[chrisliebaer]

This enables self-update to display release notes after switching to a different version.

1. If user consent is required, user is provided with release notes of target version before consenting.
2. If operation can run without user intervention, release notes are displayed after binary has been replaced.
3. New flag --release-notes-only for printing release notes without replacing binary

I am not sure if the #### New contributors and ##Download pixi... sections should be included, but removing them would require the release note format to be stable enough for parsing.

I also decided to strip the leading v in invocations like pixi self-update --version v1.2.3, making both pixi self-update --version 1.2.3 and pixi self-update --version v1.2.3 valid. I think this is more user-friendly and does not introduce any ambiguity.

Any opinions on the verbosity of the release notes?

Closes #2705

[Hofer-Julian]

Thanks @chrisliebaer, I've done a bit of limited testing and everything worked out well. Also the code looks good to me. I plan to have a closer look tomorrow.

1. If user consent is required, user is provided with release notes of target version before consenting.
2. If operation can run without user intervention, release notes are displayed after binary has been replaced.

I think it would be fine to always print the changelogs before there might be user interaction. Or did that look ugly?

I am not sure if the #### New contributors and ##Download pixi... sections should be included, but removing them would require the release note format to be stable enough for parsing.

Good idea to remove them. You are absolutely right, that it's not perfectly stable, but I think it wouldn't hurt to attempt removing it. Something like "#### New contributors" until next "#".

I also decided to strip the leading v in invocations like pixi self-update --version v1.2.3, making both pixi self-update --version 1.2.3 and pixi self-update --version v1.2.3 valid. I think this is more user-friendly and does not introduce any ambiguity.

This is a good idea. I could have sworn we already implemented that. We for sure talked about it :D

@wolfv had the nice idea to color headings. Is this something you'd be interested to tackle in this PR?

[pavelzw]

this contains a mixture of tabs and spaces. why doesn't cargo fmt catch this?

[chrisliebaer]

I think it would be fine to always print the changelogs before there might be user interaction. Or did that look ugly?

There are only a few status lines afterwards. I think it looks a bit weird to have the release notes go first, but that's just preference. The implementation would be nicer if the release notes always go first.

Good idea to remove them. You are absolutely right, that it's not perfectly stable, but I think it wouldn't hurt to attempt removing it. Something like "#### New contributors" until next "#".
@wolfv had the nice idea to color headings. Is this something you'd be interested to tackle in this PR?

I was also considering coloring the output but didn't know if you wanted to have a dependency on the formatting. If you are fine with it breaking/looking ugly in case of changes, I can do that.

This is what it now looks like:

A bit afraid to strip the "## Release notes" section, as I expect this to be the first place where someone starts summarizing bigger updates.

[ruben-arts]

Really cool! Thanks