BUG: Pinned-Dependencies need ability to exclude non-build/release workflows

[emaste]

Describe the bug
A product may have workflows that are not part of its build or release process that have unpinned dependencies. This may be incidental or intentional. Some method is needed to indicate that these workflows are unrelated to build or release processes.

Reproduction steps

1. Examine FreeBSD scorecard https://securityscorecards.dev/viewer/?uri=github.com/freebsd/freebsd-src
2. Review workflow with unpinned dependency https://github.com/freebsd/freebsd-src/blob/main/.github/workflows/cross-bootstrap-tools.yml
3. Observe that unpinned dependencies here do not affect builds or releases

Expected behavior
Some method exists to have workflows indicate that they are not part of a build or release process.

Additional context
It is presumably unfeasible to automatically detect that a workflow is not part of a build or release process, and I suspect an explicit annotation is the only feasible way to accomplish this.

The workflow referenced above is used to test that FreeBSD can be cross-built from Linux and macOS environments obtained by installing the default versions of the build tools, and pinning them would partially defeat the purpose. The workflow builds a FreeBSD kernel using the installed environment but does not store or otherwise handle any built artifacts; the output is merely whether the build was successful or not.

[spencerschrock]

Some method exists to have workflows indicate that they are not part of a build or release process.

There are two approach to this: explicit and implicit.

1. Explicitly, we have started a feature allowing repo maintainers to annotate this sort of thing. ( ⚠️ Add initial Maintainers Annotation parsing #3905)
2. Implictly, I believe what you're requesting is the discussion at Feature: Allow unpinned in non-privileged workflows #2018

Looking at the workflow now, #2018 seems more applicable given the workflow has no privileged access

[emaste]

Thanks - #3905 can be used to solve this for us in the short term, and I believe that my request is equivalent to #2018 so I'll close this.

[spencerschrock]

I'll note #3905 is still experimental