Support creation of draft release and draft PRs

[NathanReb]

The current workflow implies the creation of a Github release before being able to open a PR to opam-repo and therefore before being able to get feedback from its CI.
This means that whenever there's an issue with the release that's uncovered by opam-repo's CI, users have to delete the github release and start all over again.

The main issue here is that for popular tools, some distribution maintainers susbscribe to github releases in order to be notified when a new version comes out so they can package it for their distribution. Deleting releases can then cause trouble.

The prefered solution to this would be to have a way to trigger opam-repo CI builds in order to test a release, ie to test a distribution tarball and its associated opam files but this will require some work on ocaml-ci and will take some time before getting widely adopted.

In the meantime, it should be fairly easy to add a feature to dune-release allowing the creation of a draft release that we would only undraft once opam-repo's CI goes green and we're sure we can proceed with the actual release.

I suggest the following:

1. Add a --draft option to dune-release publish so that the release is created as a draft.
2. Add a --draft option to dune-release opam submit so that the PR is opened as a draft.
3. Add a dune-release undraft (or any better suited name) command that would undraft the GH release, update the opam-repo PR and undraft it.

Note that 2 and 3 are required because the distrib tarball link will change as we undraft the GH release, meaning we don't want the PR to be merged accidentally untill we have updated the opam file's url.src field.

[NathanReb]

To further specify dune-release undraft, here are the various steps it should take care of:

1. undraft the github release through a github API request.
2. get the new and final distrib tarball link, either from the API response from 1. or through another API request.
3. edit the opam file added to the local opam-repo clone to create the opam-repo PR so that the src.url file matches the one extracted in 2. and push these changes to the remote used to open the PR.
4. undraft the opam-repo PR through an API request.

[NathanReb]

As I wrote this I also realized that it was possible for someone that isn't using the bistro command to run publish with the --draft flag but to run opam submit without and that's pretty bad. We should probably prevent that from happening somehow, I guess we could write that information in the .url file or make it a .url.draft instead so that when someone's trying to open a regular PR referencing a link to a draft release we fail.

Doing it the other way around should be harmless even though there's not really any point to it so I guess it's okay if we don't try to prevent it from happening.