Add a ruletype for enforcing a file being present in a repo

[rdimitrov]

The following PR creates a ruletype that lets you ensure you have a certain file in your repository, but also allows you to specify its expected content.

This rule is useful for enforcing the presence of various files in the repository, such as LICENSE, README, CONTRIBUTING,
CODE_OF_CONDUCT, Dependabot configuration files and many more. It can also be used to enforce the presence of specific
content in the file so you know that the file is not just a placeholder.

Depends on mindersec/minder#5216

This ruletype also implements OSPS-DO-02

[evankanderson]

A few nits, but seems good overall.

[evankanderson]

I suspect that Dependabot is trickier, because you probably want it to be adjusted based on the languages present. The others seem fairly likely to be consistent.

[evankanderson]

Question: right now, it looks like you'd end up needing to specify N copies of the rule for N different files.

What would you think of having a schema like the following?

Suggested change

	file:
	type: string
	description: |
	The file to enforce in the repository.
	For example, LICENSE, README, CONTRIBUTING, .github/dependabot.yml, etc.
	default: LICENSE
	content:
	type: string
	description: |
	The content to enforce in the file.
	For example, the content of the LICENSE file.
	Leave "" to only check for the presence of the license file.
	required:
	- file
	- content
	files:
	type: object
	additionalProperties:
	type: string
	description: |
	A mapping from file path to expected contents in the repository
	Set expected contents to "" (empty string) to check for file existence without
	checking file contents.
	default:
	required:
	- files

[evankanderson]

Ah! This is a (current) reason not to use the object formulation -- we don't have a way to iterate over all the keys in the Profile.files map, correct?

[rdimitrov]

Exactly 👍 Of course, we can try to do that if we want. I was also thinking if I should try and make the path field optional for the pull request remediation type, but at the same time I like explicitly scoping it so you don't accidentally push another change. My concern for not looking at these is both will be considered breaking changes so I think it'll be out of scope for this one.