Allow dispatching Build Scoped Rector manually

[TomasVotruba]

Adds a workflow_dispatch trigger to build_scoped_rector.yaml, so rector-* package repositories can rebuild rectorphp/rector right after merging a pull request of their own. Companion pull request in rector-phpunit does the dispatching.

 on:
     push:
         branches:
             - main
         tags:
             - '*'
+    # allows rector-* package repositories to rebuild after their pull request is merged
+    workflow_dispatch: null

The rest of the change is what makes a dispatched run behave.

github.event.before and github.event.after only exist in the push event payload, so they are empty on a dispatched run. The git log step is limited to push events:

                 name: "Get Git log"
                 id: git-log
+                # "before"/"after" exist only in the push event payload
+                if: github.event_name == 'push'

And the commit message uses github.sha, which is identical to github.event.after on push, so push builds keep their current message verbatim:

-                    git commit -m "Updated Rector to commit ${{ github.event.after }}" -m "$INPUT_LOG"
+                    git diff --staged --quiet || git commit -m "Updated Rector to commit ${{ github.sha }}" -m "$INPUT_LOG"

The git diff --staged --quiet || guard covers a dispatched build that produces no change at all, e.g. after a test-only pull request in a package repository. Without it, git commit fails with nothing to commit and the build goes red on every such merge.

Note on ordering

A dispatch fires the moment a package pull request merges, but the build runs composer install against that package's dev-main, which Packagist can serve with a few minutes of lag. A dispatched build may therefore rebuild against the previous main. Not addressed here — a Packagist update hook on the package repositories is the proper fix, and this trigger is still useful without it.