Consider distinguishing "configuration" from "policy"

[alilleybrinker]

Right now, Hipcheck takes a configuration file (through the -c/--config flag, which specifies the directory to find the file in) which describes the analyses to run, how to run them, how to weight them for scoring, and what risk tolerance to have. This file is in effect describing the policies to apply on the analyses, and in fact I expect this perspective to get stronger with current planned changes to Hipcheck. In the plugin system, this configuration file will describe what plugins to load and what predicates to apply to the measurements produced by analyses for scoring. This is pretty strongly an expression of the user's policy toward their targets of analysis.

At the same time, we're likely to want to enable some persistent configuration of Hipcheck in the future, similarly to how Git has the .gitconfig file which specifies things like how to perform networking or how to handle calling underlying commands. Cargo has a similar notion with a configuration file which is separate from the package manifests that describe packages.

I think we could be clearer in our communication and in our CLI if we distinguished policy from configuration. In this new framing, we'd have:

• The Policy file (likely in KDL, based on the experiments and discussions so far), which replaces today's "configuration" file, and would describe the analyses to perform and how to score them.
• The Configuration file (akin to .gitconfig for Git or config.toml for Cargo) which specifies how to configure Hipcheck's execution for basics like networking or interacting with third-party tools.

The flag for specifying the configuration would become -p/--policy, and in the documentation we could more clearly talk about the "Policy" as a distinct object from configuration.

I think this would be clearer!

This sort of change would need an RFD, probably to accompany the changes being considered around the format of this policy file and whether to use KDL.

[alilleybrinker]

This ended up being reflected in RFD 4, and can be closed.