General tidy-up of tasks.

[WillB97]

This is a major restructure of the tasks to make them more understandable and easier to project manage utilising GitHub's Project boards. Various closely related tasks have been combined into a single task, with a checklist of actions to be taken to complete the task. This will make it easier to track progress and to see what needs to be done next.

As we're using GitHub task lists it's still possible to split the actions into their own issues (with a single click!) so if an area owner wants more granularity they can have it. By having a single task, it is easier to see what is left to do and to track progress.

The tasks have been deployed to the test repo and are available at: https://github.com/orgs/srobo/projects/22/views/15 and https://github.com/srobo/test/issues
This will be merged into main and deployed to the main repo on Friday 9th Feb, until then please review and comment on the changes.

Resolves #92
Resolves #91
Resolves #85
Resolves #79
Resolves #74
Resolves #72
Resolves #64
Resolves #63
Resolves #62
Resolves #52
Resolves #47
Resolves #32
Resolves #19
Resolves #53
Resolves #75
Resolves #78
Resolves #20
Resolves #51
Resolves #81

[PeterJCLaw]

Thanks for having a look at this. There's a huge amount going on here though, which is going to make review fairly involved. Do you think we could break this up a bit to ease review (the separate commits do help a bit with this, but there's still a lot here)? Perhaps breaking out the kickstart tree changes from the competition changes would help?

[PeterJCLaw]

I realise this is still work-in-progress, but another thought towards review (so you don't get too far along and need to rework stuff later) -- please keep pure content changes separate from changes to the scripts which manage the repo. I realise that things like changing the priority mapping can't avoid changing the spelling of the content files, however it's much easier to review that sort of thing in isolation rather than as part of a series which also change other aspects of the content (or code).

[RealOrangeOne]

Is this not the pre-comp storage trip?

[WillB97]

Yes, that's most of what the logistics is.

[RealOrangeOne]

Overall, I'm fairly happy with this. There might be some teething issues and nitpicks we've missed, but I think the best way to find them is by deploying it, using it, and feeding back in.

Sure, deploying something in that state isn't ideal, but the current state of the repo isn't exactly perfect either, and this PR greatly improves descriptiveness, prunes what we don't do anymore, and makes it easier to comprehend the overall status of the competition.