Allow a workflow to prematurely run the `post` phase of an action

Describe the enhancement
Allow a workflow to prematurely run the post phase of an action.

Code Snippet

- uses: aws-actions/configure-aws-credentials@v1
  with:
        aws-access-key-id: ${{ secrets.ACCESS_KEY_ID }}
        aws-secret-access-key: ${{ secrets.SECRET_ACCESS_KEY }}
- id: login-ecr
  uses: aws-actions/amazon-ecr-login@v1
- run: docker pull some-private/image-from-ECR
# This is new syntax:
- cleanup: aws-actions/configure-aws-credentials
- cleanup: login-ecr
- run: yarn install

Additional information
I am coming from the context of Dependabot update PRs, where sooner or later I will need to run some tests on untrusted and possibly malicious code. This is illustrated by the yarn install step above, which might run malicious lifecycle scripts. It's not the lifecycle scripts per se – there is plenty of ways how code might get run, and I cannot get around all of them. Sooner or later I will have to run the code in question.

Some of these workflows will also have to deal with secrets/sensitive data, for example when I need to pull a Docker image from a private registry in order to run my tests.

In that situation, I'd like to do "trustworthy" things first, then clean up as much as possible before running the "untrusted" parts. In the example, "cleaning up" would mean to run: docker logout and to reset (or even unset) environment variables.

However, it can be hard for me to tell what it takes to clean up an action's results. The action itself should know best. The aws-actions/* from the example already do cleanup homework in their post phase/file. So, let me invoke that at a point before my job terminates, instead of at the end of the job.

In my example above, cleanup: refers to one action by name and to the other one by id. I don't mind – maybe the id is more precise? Surely there is some ambiguity when an action is used several times throughout a workflow.

Start by tracing how the runner schedules an action's post phase and how workflow steps identify actions; the issue names action names and step ids as possible cleanup targets. Resolve repeated-use and ordering semantics, then verify that the proposed cleanup syntax can trigger post phases before later untrusted steps and still preserve normal job-end cleanup.