Support result mode for multiple jobs usage

The examples of this action show the multiple job support with the manual result reporting.

- https://github.com/github/branch-deploy/blob/main/docs/examples.md#multiple-jobs

However, the example implementation needs to maintain a huge result reporting steps on users side, and it reduces the benefit of the branch-deploy action that wraps the complexity of the branch-deploy process.

The result report steps from an example

```yaml
# update the deployment result - manually complete the deployment that was created by the branch-deploy action
result:
needs: [trigger, build, deploy]
runs-on: ubuntu-latest
# run even on failures but only if the trigger job set continue to true
if: ${{ always() && needs.trigger.outputs.continue == 'true' }}

steps:
# if a previous step failed, set a variable to use as the deployment status
- name: set deployment status
id: deploy-status
if:
${{ needs.trigger.result == 'failure' || needs.build.result == 'failure' ||
needs.deploy.result == 'failure' }}
run: |
echo "DEPLOY_STATUS=failure" >> $GITHUB_OUTPUT

# use the GitHub CLI to update the deployment status that was initiated by the branch-deploy action
- name: Create a deployment status
env:
GH_REPO: ${{ github.repository }}
GH_TOKEN: ${{ github.token }}
DEPLOY_STATUS: ${{ steps.deploy-status.outputs.DEPLOY_STATUS }}
run: |
if [ -z "${DEPLOY_STATUS}" ]; then
DEPLOY_STATUS="success"
fi

gh api \
--method POST \
repos/{owner}/{repo}/deployments/${{ needs.trigger.outputs.deployment_id }}/statuses \
-f environment='${{ needs.trigger.outputs.environment }}' \
-f state=${DEPLOY_STATUS}

# use the GitHub CLI to remove the non-sticky lock that was created by the branch-deploy action
- name: Remove a non-sticky lock
env:
GH_REPO: ${{ github.repository }}
GH_TOKEN: ${{ github.token }}
run: |
# Fetch the lock.json file from the branch
gh api \
--method GET \
repos/{owner}/{repo}/contents/lock.json?ref=${{ needs.trigger.outputs.environment }}-branch-deploy-lock \
--jq '.content' \
| base64 --decode \
> lock.json

# Check if the sticky value is true
if [ "$(jq -r '.sticky' lock.json)" = "true" ]; then
echo "The lock is sticky, skipping the delete step"
else
# use the GitHub CLI to remove the non-sticky lock that was created by the branch-deploy action
echo "The lock is not sticky, deleting the lock"
gh api \
--method DELETE \
repos/{owner}/{repo}/git/refs/heads/${{ needs.trigger.outputs.environment }}-branch-deploy-lock
fi

rm lock.json

# remove the default 'eyes' reaction from the comment that triggered the deployment
# this reaction is added by the branch-deploy action by default
- name: remove eyes reaction
env:
GH_REPO: ${{ github.repository }}
GH_TOKEN: ${{ github.token }}
run: |
gh api \
--method DELETE \
repos/{owner}/{repo}/issues/comments/${{ needs.trigger.outputs.comment_id }}/reactions/${{ needs.trigger.outputs.initial_reaction_id }}

# if the deployment was successful, add a 'rocket' reaction to the comment that triggered the deployment
- name: rocket reaction
if: ${{ steps.deploy-status.outputs.DEPLOY_STATUS != 'failure' }}
uses: GrantBirki/comment@e6bf4bc177996c9572b4ddb98b25eb1a80f9abc9 # pin@v2.0.7
with:
comment-id: ${{ needs.trigger.outputs.comment_id }}
reactions: rocket

# if the deployment failed, add a '-1' (thumbs down) reaction to the comment that triggered the deployment
- name: failure reaction
if: ${{ steps.deploy-status.outputs.DEPLOY_STATUS == 'failure' }}
uses: GrantBirki/comment@e6bf4bc177996c9572b4ddb98b25eb1a80f9abc9 # pin@v2.0.7
with:
comment-id: ${{ needs.trigger.outputs.comment_id }}
reactions: '-1'

# if the deployment was successful, add a 'success' comment
- name: success comment
if: ${{ steps.deploy-status.outputs.DEPLOY_STATUS != 'failure' }}
uses: peter-evans/create-or-update-comment@67dcc547d311b736a8e6c5c236542148a47adc3d # pin@v2.1.1
with:
issue-number: ${{ github.event.issue.number }}
body: |
### Deployment Results ✅

**${{ needs.trigger.outputs.actor_handle }}** successfully deployed `${{ needs.trigger.outputs.sha }}` to **${{ needs.trigger.outputs.environment }}**

> [View Live Deployment](${{ env.blog_url }}) :link:

# if the deployment was not successful, add a 'failure' comment
- name: failure comment
if: ${{ steps.deploy-status.outputs.DEPLOY_STATUS == 'failure' }}
uses: peter-evans/create-or-update-comment@67dcc547d311b736a8e6c5c236542148a47adc3d # pin@v2.1.1
with:
issue-number: ${{ github.event.issue.number }}
body: |
### Deployment Results ❌

**${{ needs.trigger.outputs.actor_handle }}** had a failure when deploying `${{ needs.trigger.outputs.sha }}` to **${{ needs.trigger.outputs.environment }}**
```

Therefore, I would like the branch-deploy action to support the `result` mode (or separate action) to wrap the result reporting process.

Thanks.

## Reference

- https://github.com/github/branch-deploy/issues/154

Inizia da docs/examples.md, nell’esempio multiple-jobs, e consulta la discussione correlata nell’issue #154. Traccia come la branch-deploy action espone attualmente gli output del deployment e determina l’interfaccia result-mode e il comportamento del workflow; il lavoro è completato quando più jobs possono segnalare gli esiti del deployment senza il grande workflow manuale di reporting.

Scritto dal modello di indicizzazione a partire dal testo della issue.