Add winget publish github action

[brl0]

This adds a github action to publish the windows version to the winget-pkgs repo. The winget-releaser github action requires a personal token as WINGET_TOKEN. Details for configuration are here: https://github.com/vedantmgoyal2009/winget-releaser

For now, I have also submitted a PR to winget-pkgs to update to the current version, using the underlying tool utilized by this action.

This is my first attempt at configuring this as an action, so please let me know if there are any questions, concerns, or issues.

Thanks!

[vedantmgoyal9]

Before merging, there are 2 things that need to be done:

1. Please add a GitHub token with public_repo and workflow scopes as a repository secret and rename the secret name in the workflow.
2. Fork microsoft/winget-pkgs under @jupyterlab.

[mbektas]

It is not ideal for us to fork microsoft/winget-pkgs under https://github.com/jupyterlab. we were expecting someone from community to update winget-pkgs repo as needed. It appears publishing winget package will require us to maintain it. any thoughts @krassowski?

[vedantmgoyal9]

@mbektas if that's the case, then any maintainer can fork winget-pkgs repo under their personal account and the workflow will be updated accordingly.

[krassowski]

It is not ideal for us to fork microsoft/winget-pkgs under https://github.com/jupyterlab.

I think we can keep a fork under a bot account, the fork location appears customisable as per https://github.com/vedantmgoyal2009/winget-releaser#use-fork-under-which-user-fork-user.

It appears publishing winget package will require us to maintain it. any thoughts @krassowski?

If this is running on CI with minimal maintianer intervention I would be fine to proceed. However, I am a bit concerned with using vedantmgoyal2009/winget-releaser action without hash pin - it is unofficial and not too widely used. I would recommend to pin to a hash if were to merge it. There are plans to upstream it as per microsoft/winget-pkgs#500 (comment) so it seems promising long-term.

There is another, simpler way to handle this without a CI action on our side nor a fork, by using a "vanity URL" as per microsoft/winget-pkgs#500 (comment). We are already discussing a possibility of using vanity URLs in jupyterlab/jupyterlab#14675 (comment) (CC @fcollonval, @paddymul) so maybe having a vanity URL per OS and one catch-all coud be the way to go.

[mbektas]

@brl0 @vedantmgoyal9 thanks for the contribution, I will merge and wrap it up.