ci: remove toolchain adjustments

[evilrobot-01]

Summary

Closes #2458

• [n] y/n | Does it introduce breaking changes?
• [n] y/n | Is it dependent on a specific version of cargo-contract or pallet-revive?

Updates CI workflow to use a new Docker image (use-ink/docker-images#4) with some image optimisations, along with updates to the scripts which were removing toolchains defined in the CI image to free up space.

Requires use-ink/docker-images#4 to be merged and a new CI docker image to be built/published.

Description

The PR introduces two new reusable actions: .github/init for intializing a runner in each job and .github/run-container-command) for executing a batch of commands within a container.

Each job runs in its own runner instance and therefore needs to have space cleared and caching setup. The init action standardises this approach in a somewhat configurable/flexible way. About 45GB is available after using the init action. Removing data does take a little time, so it should therefore only be used on jobs which actually require the space. The improved useink/ci image is 1.32GB compressed/~4.3GB uncompressed, leaving ~40GB free for jobs. All toolchain removals, CARGO_INCREMENTAL and partitioning has been removed as a result. The action also optionally sets up Rust caching, mostly so this is defined once and it is clear that it is per runner/job. Additional caching by matrix value is possible.

The run-container-command action allows commands to be run within a container AFTER space has been cleared, which is important as the same runner disk is used for both the job, the pulled docker image and then the results of the job within the container. Using the container attribute sadly does not allow for space to be cleared prior to the container being launched, necessitating this action. The workspace on the host is mapped into a different path in the container, requiring a few adjustments to the directory paths for effective caching.

Notes:

• Each job using a container pulls the docker image which takes about 30 secs. Attempts at caching the docker images resulted in about the same amount of time but with added complexity and additional cache storage requirements. It therefore didnt seem worth pursuing at this time.
• There are some jobs which may benefit from better caching, but that is considered out of scope for this PR.

Checklist before requesting a review

• I have added an entry to CHANGELOG.md
• I have commented on my code, particularly in hard-to-understand areas
• I have added tests that prove my fix is effective or that my feature works
• Any dependent changes have been merged and published in downstream modules

[davidsemakula]

Looks great!
Thanks @evilrobot-01