Hotfix for the setup action

[mmhat]

In #47 we moved the setup of the get-tested tool to an own reusable action called the setup-get-tested action.
There, the setup-get-tested is referenced in the get-tested action using a relative path ./setup-get-tested as it was assumed that this resolves to the location of the of the cloned get-tested repository when the get-tested is used by another project.
It turns out the assumption was wrong, hence we need to reference the setup-get-tested action in the get-tested action using the OWNER/REPO[/PATH]@REF syntax.

[mmhat]

One problem remains: When someone wants to use a specific version of the get-tested action, say Kleidukos/get-tested@123, the setup-get-tested action used internally should be the one of the same ref, i.e. Kleidukos/get-tested/setup-get-tested@123. Ideally we don't want to hardcode the ref in there, but apparently there is no (clean) way to do that.
See actions/runner#895 for the related issue.

[Kleidukos]

Should we roll-back the setup-get-tested thing this gets resolved by GitHub then?

[mmhat]

Should we roll-back the setup-get-tested thing this gets resolved by GitHub then?

I don't think that is necessary. For now I pinned the used setup-get-tested action to v0.1.8.0 and it can stay on this version as long as we don't change the setup-get-tested action: Note that the downloaded get-tested binary is "opaque" to the setup-get-tested action -- We do not make any assumptions about any functionality present/absent in the binary.
This solution is IMHO a bit awkward, but not completely terrible.

The failing check is completely unrelated to the changes here; There appears to be some problem with the get-tested-head job.

[Kleidukos]

@mmhat would you mind rebasing your commits on main?

[mmhat]

@Kleidukos I rebased the changes. I also used an commit SHA to pin the setup-get-tested action used in the main action.
Before, I used a tag, but the only release that contained the setup-get-tested action was broken and removed accordingly.
We should go back to using a stable release tag in the main action once a new (working) release is published.