The current example of how to use `@actions/cache` with pipenv has two
problems:

 1. The cached virtualenv that pipenv creates has `bin/python` as a symlink
    into paths like `/opt/hostedtoolcache/Python/3.7.11` that explicitly
    include the patch version of python. When the cache is restored onto a
    machine running a slightly different version of python, e.g., when
    GitHub upgrades its runners from python 3.7.10 to 3.7.11, then any
    attempt to run python in the workflow mysteriously fails with errors
    like `Failed to load paths: /bin/sh: 1: /home/runner/.local/share/virtualenvs/myrepo-sOIMCiTO/bin/python: not found`.

    Therefore the patch version of python should be included in the cache
    key.

 2. `pipenv --install` has the unfortunate behaviour of not cleaning out
    any pre-existing packages. That is, if the `Pipfile` first contains
    dependencies on `foo` and `bar`, and then you remove `bar` from the
    `Pipfile` and run `pipenv install` again, `bar` is still included in
    the virtualenv.

    This can cause false-positive test failures: when a dependency is
    removed from the `Pipfile` but there is still code that relies on the
    removed dependency, tests can still pass if the dependency comes from
    the cache based on a previous revision of `Pipfile.lock`.

    Therefore `restore-keys` should not be set.

This PR attempts to address both of these issues.