Split unpinned-uses into two separate checks

[funnelfiasco]

Here's my first pass at implementing #179. The code is there and functional, AFAICT. I've tested it against a real workflow file that uses repo paths. I don't have any handy that use Docker, but if I understand the model correctly, it's very straightforward to check it and so my code will Just Work™.

I will add tests and docs before I remove the "WIP" from this, but I wanted to make sure what I've done here is generally acceptable before I put effort into that part.

Since most of the "what to do if we find an unpinned uses of either flavor" is repetitive, I tossed in a flag instead of repeating that code.

There's a lot of "not" in the new function I created in the model. It could have been written a little more cleanly without the negations, but that kept the usage the same as in the existing unpinned(), which seemed more important.

Of note, this only looks to see if the pin looks like a SHA. It does not attempt to verify that such a SHA actually exists. You probably expect that, but I wanted to be explicit about it (and I will be in the docs updates, when I create them)

Edit to add: I have also not run fmt or clippy yet, since it seemed like something that could wait until I got a thumbs up on the general direction.

Fixes #179

[woodruffw]

Thanks @funnelfiasco! The overall approach here LGTM; I left a couple of nits. If you want to run cargo fmt and cargo clippy internally then I can do a full review pass.

[funnelfiasco]

Updated based on feedback:

• Used is_some() for the Docker hash instead of ! .is_none()
• Renamed new function unhashed
• Dropped use of pedantic in favor of marking unpinned as medium severity and unhashed as low severity
• Used ref_is_commit and dropped regex
• Ran fmt and clippy

Todo, pending approval of these changes:

• Docs
• Tests
• Squash commits

[funnelfiasco]

Rested, tested, and ready for review

[woodruffw]

Thanks! I'll do a review pass tomorrow.

[funnelfiasco]

Updated based on feedback

[woodruffw]

Thanks, LGTM! I thought about it a bit more and I'm mildly worried that having the unhashed() check by default (vs. pedantic) is going to cause too much alert fatigue for most CI users. But that's not a blocker here, since this is a good impetus for me to rethink the sensitivity defaults/flags.