ci: fix project-autoadd github action

[jdrueckert]

Contains

A fix for the project-autoadd github action which failed because the utilized underlying action only supports classic projects but we're using v2 (beta) projects. The replacement action not only works but is a base action provided by GitHub which hopefully means better maintenance and higher security awareness.

The action requires a token with control privileges for projects. I added such a token to the organization secrets and wrote a maintainer guide on what to do in case the action starts failing because this token expired.

How to test

Add a new label to the PR (ideally remove it again afterwards so we don't clutter the PR with arbitrary / not applicable labels).
The action should run automatically in the PR checks. If not, a new run should be accessible at https://github.com/MovingBlocks/Terasology/actions

Outstanding before merging

• verify that the action no longer crashes
• optional: play around with the labels in this PR and verify that the issue is added to boards accordingly

[jdrueckert]

While adding items to boards does seem to work without problems now, moving an item to a specific column does not.
It currently fails with the error: Item not found with ID 'PVTI_lADOABO4ms4AIY3szgDbUNI'.
I have no clue yet, why it cannot find the item ID and didn't dive deep enough into GitHub RestAPI yet to figure out how to check the board for the contained items and them for their IDs.

I see two options on how to continue with this:

1. Remove the action steps that move the items to a specific column - this will result in the items being in a "No Status" column (see https://github.com/orgs/MovingBlocks/projects/29/views/1 for instance). IMO this would be acceptable for now.
2. Continue to investigate this - next step would be to query the IDs of items on board 29 and checking if there is an item with ID PVTI_lADOABO4ms4AIY3szgDbUNI - if so, it could maybe be a permission issue, if not the ID returned by the add-to-project as itemID is not the one we want (either it's incorrect or we need to reference a different field of the output)

[jdrueckert]

I decided to go with option (1) as it really doesn't matter too much whether the cards are in a "No Status" or a "Backlog" named column... Having them outside of the backlog list even gives us the opportunity to decide whether or not to add it to the backlog in the first place. We may also simply want to remove it from the board because it's not actionable in the near future.