CI is double-running on PRs

[pbeaucage]

Describe the bug
All CI tests, installers, and doc builds are running twice on commits to branches once a PR is created. Simple origin, most of our GH actions scripts use a trigger of [push,pull_request]

I propose that we run tests on [push], installers on [pull_request] and docs probably also on [push].

To Reproduce
PR commits have 24 run tests instead of the proper 10.

Expected behavior
Tests should not be duplicated.

[llimeht]

Running the unit tests only on push would potentially mean that the merged version doesn't ever get tested. Except in the situation where the merge will be a fast-forward, they are running adding different code.

For work in progress branches, potentially all three sets of tests need to be run. For merges, all three also need to be run. I'm not sure how to reduce the runs, or if it's even worth doing.

[pkienzle]

Back to the ticket:

Tests are running on both push and pull_request. Propose running them only on push. Concern is that push doesn't catch merge requests.

Looking at the docs we should should ignore most pull_request triggers. Just adding a comment to the discussion should not cause a rebuild.

The merge action isn't even listed in the pull_request activity types, so does it even solve the merge problem?

We shouldn't need to run tests on the pull_request open activity since it should have been built and tested on the push. However, I wouldn't be surprised if it didn't show the last build activity before the PR, so this might be the most expedient way of having the test results appear.

The git fork vs. branch workflow doesn't seem relevant to the issue.