Refactor into a composite action

[woodruffw]

Closes #8.
Closes #2.

[woodruffw]

This works, but some open questions:

1. How do composite actions interact with their parent workflow? I don't have to install python or any other state here, presumably because I'm running in the ubuntu-latest instance defined in the parent workflow, but can I rely on this? Should the action opportunistically use actions/setup-python if it can't detect a modern enough Python?
2. How does this interact with the target repository's working directory? Normally it's the $CWD after an actions/checkout, but we don't guarantee that here.
3. How should this interact with virtual environments? Right now this action is completely unaware of them (and was before as well)

[woodruffw]

1. How do composite actions interact with their parent workflow? I don't have to install python or any other state here, presumably because I'm running in the ubuntu-latest instance defined in the parent workflow, but can I rely on this? Should the action opportunistically use actions/setup-python if it can't detect a modern enough Python?

I think the answers to this are "technically no, but yes" and "depends on the first."

In principle it's a user error to attempt to run pip-audit on a host that doesn't have Python installed, since there's no Python environments whatsoever to audit. But maybe that's too legalistic of us, since someone might want to audit a fully-resolved and hashed requirements file without worrying about the rest of the Python environment? We should probably support that case.

If the first is "no", then the second is definitely "yes."

[woodruffw]

2. How does this interact with the target repository's working directory? Normally it's the $CWD after an actions/checkout, but we don't guarantee that here.

I'm not 100% sure about this, but I think this will end up being a non-issue. I suspect that this action will inherit the $CWD from the checkout, since that's what seems to happen implicitly with every other action in the GitHub Actions ecosystem.

[woodruffw]

3. How should this interact with virtual environments? Right now this action is completely unaware of them (and was before as well)

For this, we should probably figure out a configuration setting. Something like venv: path-to-dir/, which we'd then...opportunistically load into the environment, right before action.py? Or something similar? Or maybe we just add ${{ inputs.venv }}/bin to the head of the $PATH and let pip to the rest?

[woodruffw]

The venv self-test is blocked on a fix for pypa/pip-audit#156.

Edit: Unblocked by installing pip-audit into the venv, which hides the bug.