add support for manually setting outcome

[alexrashed]

Motivation

We have seen some instances in the past where the usage of this action was causing some issues, if the action was used in sub-workflows (which were triggered with the workflow_call trigger).
This is because the action really goes through all the jobs in the (complete, in this composite) workflow and checks all the outcome.
This means that this action can:

• Report failure even though all jobs in the specific workflow where it's defined were successful.
• Not be triggered if one uses the "rerun from failed" feature of GitHub actions, because the reporting step obviously does not define the failed step - defined in a completely different workflow - is not a dependency (defined by "needs").

Unfortunately, it's not possible to access the needs context from within a GitHub action (which would allow filtering the jobs to check for the ones the action depends on).
This is why this PR provides a different solution: It allows the user of the action to manually set the outcome (instead of letting the action detect the outcome). At the level of the action definition, the needs context can be accessed and can be used in a simple evaluation over all declared dependencies as follows:

${{ (contains(needs.*.result, 'failure') && 'failure') || 'success' }}

Which means the issue can be circumvented with a usage of the action like this:

  - name: Push to Tinybird
    if: always()
    uses: localstack/tinybird-workflow-push@v3
    with:
      github_token: ${{ secrets.GITHUB_TOKEN }}
      tinybird_token: ${{ secrets.TINYBIRD_TOKEN }}
      tinybird_datasource: <your-data-source>
      workflow_id: <custom-workflow-id>
      outcome: ${{ (contains(needs.*.result, 'failure') && 'failure') || 'success' }}

Changes

• Provides a new optional parameter (non-breaking change) to manually set the outcome which should be reported to Tinybird.

Testing

• We tested this change in one of our private repos where we saw this issue regularly.

[silv-io]

LGTM! Just some alternative idea to how to solve this. But the chosen fix is good as well.