Trigger workflows more selectively

[scotts]

I'm trying to make our workflow triggering smarter. For example, when we're making doc changes, we're still triggering Mac and CUDA wheels, and those jobs take a long time and we just ignore them anyway. I'm less concerned about wasting resources, and more concerned about making sure we see important signals. All workflows have a self reference. In addition to that, my reasoning on why triggering what when:

build_ffmpeg.yaml
Only triggered when the script itself is updated. The script has no dependence on our code.

cpp_tests.yaml
Triggered when anything under src/torchcodec/* or test/* is changed. That means Python only changes will also trigger these tests, but I think trying to differentiate at that level is going to be too subtle and error prone. Doc changes do not trigger the C++ tests.

docs.yaml
Triggered when anything under src/torchcodec/* or docs/* is changed. Our source code has docs, and obviously we build the docs when docs files change. Notably we don't need to trigger the docs when tests change.

linux_wheel.yaml, linux_cuda_wheel.yaml, macos_wheel.yaml
All are triggered when anything under src/torchcodec/*, test/* or packaging/* is changed. These are our main test drivers, so we want these to run when all source code, tests or packaging scripts change. Doc changes do not need to trigger wheel builds and tests.

reference_resources.yaml
Only triggered when the script itself is updated. The script has no dependence on our code.

[NicolasHug]

Thanks @scotts , this looks good, happy to try this out. The best way to test this probably is to merge the PR and pay extra attention to the CI signals within the next few days.

Doc changes do not need to trigger wheel builds

Note that this may soon be the case, depending on how we go with #335, but this PR can be merged first nonetheless.