feat: add validity check to Electron Archaeologist runs

[alicelovescake]

This PR fixes #41 :

• Adds a new function getCheckStatusItems to handle the check status based on the presence of changes and semantic versioning labels in pull requests.
• Created unit tests to validate the behavior of the getCheckStatusItems function under various conditions.
• Added a bunch of jest related packages and config to enable test running in this repo

Note: Not 100% CI configs are correct, mostly copied over from Trop

[codebytere]

@alicelovescake this repo's circleci config is used for the TypeScript comparison - it doesn't run tests at the moment. Potentially it might be easier to extract that aspect to a GitHub Action like the lint job?

[alicelovescake]

@alicelovescake this repo's circleci config is used for the TypeScript comparison - it doesn't run tests at the moment. Potentially it might be easier to extract that aspect to a GitHub Action like the lint job?

Thanks for the pointer! Yeah I wasn't confident whether to put the test in the circle ci or github. Updated PR with new github workflow.

[MarshallOfSound]

There needs to be a way of overriding this

[MarshallOfSound]

There needs to be a way of overriding this, something like like our fast-track or skip-backport-check labels to bypass trop / cation checks.

This isn't 100% provably correct, for instance:

• You can make a semver/major change with 0 API surface changing, for instance enabling a feature by default (Cooke Encryption comes to mind as a semver/major with 0 API)
• You can make a semver/none change that modifies the API surface. For instance docs fixes commonly "modify" the electron.d.ts file but don't actually change the API surface. So unless this check gets smarter around diffing actual API surface rather than just the electron.d.ts file we need a way to say "in this case we're all good"

[alicelovescake]

Thanks for pointing out the edge cases that I haven't considered!

I can add a new label that's skip-type-diff-check but do you think it adds unnecessary complexity to the process? After all, the primary purpose of these checks is to provide informational cues to users.

What if for expected valid changes, we set the status to CheckRunStatus.SUCCESS and for suspected invalid changes, we set the status to CheckRunStatus.NEUTRAL with a summary that gives a warning that unexpected changes exist but feel free to skip if it's intentional.

This way, it serves the purpose of providing information without adding process overhead. If we feel like the override tag is better, happy to add it!!