🛤️ Tracking: Hipcheck against package lock files

[j-lanson]

@mchernicoff has identified running Hipcheck as a GitHub action as a use-case of interest. Essentially, a GitHub action would run Hipcheck against all the dependencies in a project passed as a lock file (Cargo.toml / Cargo.lock, package.json, etc.). This has two important differences with how we run Hipcheck currently:

1. A lock file contains lots of dependencies, it would be very inefficient to start Hipcheck, start and configure plugins, analyze, and tear down for each of those dependencies. Instead, we should refactor Hipcheck so that we can keep our plugins running and start analyzing new targets in a single Session. Additionally, we may want to support multiple Hipcheck instances working off of a single HC_CACHE, so we would need to ensure synchronization between Hipcheck instances when updating caches.

2. We would want to cache Hipcheck output in HC_CACHE, where the key is (target, policy_hash) (also maybe policy_path) and the value is (JSON report). The only problem with this is that changes to sub-config files like Binary.kdl are not captured by hashing the policy file, and we can't "know" which config fields constitute sub-config files. So we may need a CLI flag like --rerun to force hipcheck to re-run even if there is a cache entry. We may want a new hc cache report subcommand to delete stale report cache entries as well.

To support #1, we'd probably introduce a new TargetSeedKind for package files, and alter the API for TargetSeedKind -> TargetSeed so it produces an Iterator of targets that can be applied to a Session in serial

• Write RFD describing proposed changes to HC core to support multi-Target #962
• Write RFD describing proposed changes to HC core to support Report caching