Make AutoMerge guidelines checks part of the public API

[iamed2]

Right now, the public API only includes run, which couples the checks to the interactions with the git hosting service. For private registries, it would be nice to be able to run each guideline and get results, and depend on the ability to do that as well as the guidelines themselves as part of the public API, in order to avoid pinning RegistryCI.jl to an old version.

[ericphanson]

I believe we've historically only added new checks as either turned-off by default, or as a breaking release. So we've been treating it as part of the public API, as it is the functionality of what run does. Unless this is about something specific that we did which violated that?

[iamed2]

Right now run is unusable in our environment due to its tight coupling to GitHub's API. So we're looking for lower-level functionality to be made a part of the public API.

My main concern was running this on a new hosting provider that doesn't exist in the list (GitLab). When I wrote this, the get_automerge_guidelines function was not factored out and the only way to run guidelines was to be using GitHub. That refactoring is an important step forward that partially addresses this issue.

While the check functions still rely on data from a struct like GitHubAutoMergeData, many can be collected and called by something that implements the correct fields but doesn't have the GitHub-specific API field. I'm not as concerned about the list remaining exactly the same as I am on a) the ability to run a specific guideline and depend on that continuing to be available (and not suddenly requiring API access) and b) the ability to get a default list of guidelines (get_automerge_guidelines).

Factoring out the GitHub API object using something like the GitForge.jl abstraction would be the best case for us, but stable lower-level access allows us to start using some of the guidelines that don't depend on API access.

[ericphanson]

Ahh ok, thanks for explaining, I misunderstood. Makes sense!