finer grained controls for what triggers a job

Today, jobs are triggered whenever at least one of these actions occurs:

• a push is made to the repository (any branch name)
• a pull request is opened against the repository (from some other fork on GitHub)

Note that jobs are run for unique GitHub Check Suites, and there is generally a 1:1 relationship between a specific git commit (based on the commit hash) and a Check Suite; if a job would be triggered by both a pull request and a push to a branch, we still only run it at one time.

Occasionally a job will represent the combination of:

• expensive to build and creates large output objects
• is only needed for final integrated changes on the default branch, not for personal branches or pull requests

The per-job configuration should allow finer control over the events that will trigger a job to run, allowing for a list of patterns to match branch names, and the ability to ignore pull requests.

No files, tests, or entry points are named. Start by tracing how jobs currently respond to push and pull-request events and where per-job configuration is parsed; define the configuration needed for branch patterns and ignoring pull requests, then verify that each event combination triggers the intended jobs without duplicate Check Suite runs.