feat: Support filtering workflows using on.<> filters and events

[john-tipper]

resolves #2489

This PR adds a non-breaking change to add a --apply-event-filters flag.

• When not set, there is no change to Act's existing behaviour.
• When set, Act will filter workflows using the on.<> filters (paths, paths_ignore, tags, tags_ignore, branches, branches_ignore).

Limitations:

• for push events, filtering paths is done using the commits referenced in the GitHub Webhook event which I think this is where GHA gets its information.
• for pull_request and pull_request_target events, there is no guarantee that Act will actually be running with access to the actual git repo that's in GitHub (either locally on disk or via the network). I've elected for now to not handle this case, so workflows that set path filters.

More detailed thoughts on paths and pull request events:

GitHub says it does a 3 dot diff between base and head (https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-comparing-branches-in-pull-requests)

"The three-dot comparison shows the difference between the latest common commit of both branches (merge base) and the most recent version of the topic branch."

We could get the 2 SHA values from githubPullRequestEvent, but we'd have to decide whether we want to:

• read from git on disk to perform the diff, perhaps from working directory or by reference to the path of the workflow files
• clone from repo (requires credentials)
• use the GitHub API (requires credentials)
• do something else
• do nothing

I've elected to do nothing for now, happy to consider adding this in later if we can agree the way forward.

Additional changes:

I removed a section of dead code around filtering, given that it just fed the list/graph output but didn't do anything else. That printing logic has been moved further down in root.go to be able to use variables that are defined later.