New contributors can just indicate that they are working on the issue
without requesting assignment.

That shouldd reduce the burden of assigned issues that are not actually
being worked on, and new contributors waiting for a maintainer to
asssign them the issue.

---------

Co-authored-by: Danny Mösch <danny.moesch@icloud.com>

This script is not working any more in the GitHub actions jobs and I
can't reproduce this locally, so I've added some debug output to try to
help find the problem.

It's common to use the /cherry-pick command on a PR to create a backport
request. However, this creates a lot of clutter in the LLVM Release
Status project, because we end up with two items in the project, one for
the original PR and one for the new PR.

This change will set the status of the original PR to Done once the new
PR (for the release branch) is created. This will save release managers
a lot of work of having to manually updated the status for PRs that
contain backport requests.

* Greet the user and ask them to read the developer policy.
* Post their contribution stats on the issue.

GitHub won't reflow the text unless we put it all on one line.

If we try to make our own paragrpahs it comes out too narrow or
too wide.

We need to use the issue-write workflow to write the comments, because
pull_request targets don't have permissions to write comments.

We have been collecting release notes from the PRs for most of the
18.1.x releases and this just helps automate the process.

The answer to many requests in issues to be assigned to users is often
"just create a pull request". That's in contradiction to the
"introductory issue" instructions posted by the GitHub bot.

This change updates the instructions, mentioning the shortcut of "just
creating a PR". Moreover, it now explains linking PRs to issues in order
to close them automatically upon merge.