Create a tool that Eclipse committers can use to understand how to make their projects better conform to Eclipse open source project practices

I'd like a create a command-line tool that committers can use to understand (and possibly mitigate) how their project can better conform to established open source practices in general and the Eclipse Foundation Development Process in particular.

My thinking is that we can apply some heuristics to the data collected in #12 (which potentially makes #12 a blocker) to highlight when:

• the project has no project leads (red flag);
• the project has only one project lead (yellow flag);
• the project has no committers (red flag);
• the project has only one committer (yellow flag);
• one or more project repositories is missing a README, LICEN[CS]E, NOTICES, CONTRIBUTING, or SECURITY file;
• one or more project repositories is missing automated build configuration (yellow flag);
• the project has not engaged in the IP Due Diligence Process; and/or
• the project has no SBOM (yellow flag).

This list is not intended to be comprehensive. We should develop this in a manner that it can be relatively easily extended to include additional checks.

If we're able to get particularly clever:

• the project has no commits attributed to non-committers (yellow flag)
• the project has no interaction with the non-committer community (yellow flag)
• a contributing file does not describe the ECA requirement
• a contributing file is does not describe the terms of use
• a NOTICES file does not contain a cryptography statement

We might consider extending the tool to add missing information. We could potentially, for example, generate a default README or CONFIGURING file based on information in the API data.

We should not limit ourselves to CLI. We should consider how we might, for example, integrate this with the Eclipse IDE, Eclipse Theia, and/or VisualStudio Code.

Notes:

• a project may have more than one repository; we might consider making it so that the tool can make its recommendations based on the the state of all repositories, or just a subset of them
• the Eclipse Vhant project has an example specification that describes how to interpret project metadata to identify all project repositories

The implementation will be made open source under the Eclipse Dash project. Let's use this issue to discuss high-level requirements. When we're ready to start this work, we'll propose this to the Eclipse Dash project, and create a repository for the work. More detailed discussion should be held in a Eclipse Dash project repository's issue tracker.