Run package review CI on repos not packages

[braver]

From the discussion in #66, from #66 (comment) onwards, about what the a new package review tool (to be used in the default channel and registries like those for LSP and SublimeLinter) should do.

Maybe leave this here for some time so others can respond and maybe have different ideas. And I might be missing use cases here.

But I would propose this:

The GitHub workflow supports open source projects only and will run the package tests on a git repository HEAD, ie. the one linked in the details key. If tests need to be run on a "compiled" package instead, this can be done outside of CI by downloading a package zip and feeding it into the review tool locally on a command line.

Running the review workflow on packages, not just a repo HEAD, complicates the tools needed to do so, and requires tags to be created for each test (making iterative improvements harder). In other words, it would lead to a more elegant tool and it would have practical benefits if we simply inspect a repository instead of a package.

There is no immediate urgency to decide something, but the tools we use need work at some point. So, if anyone has any related thoughts, let's discuss for a moment.

[FichteFoll]

Perhaps we should clarify in which situation what would be reviewed exactly. From they context of #66, I'm continuing with the assumption that the use case is reviewing a package addition to a PC channel.json or repository.json file (default or not).

Imo, only looking at the repo HEAD is not going in the right direction for several reasons:

1. Some repos use multiple branches in the same repo to distribute a package for multiple editors. This method would never be able to figure out which branch to use if it didn't directly apply the tag prefix parsing logic that PC supports.
2. People very frequently forget to push a new tag with changes that were requested during review and this is easily discovered by the review happening on the latest tag and not HEAD.
3. If the logic is implemented to check for the latest tag of one release channel (prefix logic), it would be trivial to do the same for all other releases that target different ST versions. Otherwise those releases could do whatever and we would never find out because honestly I mostly reviewed the package for the latest ST version only (which is generally equivalent to the HEAD).

[braver]

On paper, st-package-reviewer-action wraps st_package_reviewer. In reality the st_package_reviewer portion of it has deviated, but that's an implementation detail. Effectively we're looking for a new version of, or approach to, st-package-reviewer-action.

[braver]

Actually, we've looked at the deviations and they don't seem to be very relevant. So it's safe to consider the action to already be "just" a wrapper around the reviewer, and the reviewer can be considered "fine" as is.

[kaste]

I think I have it.

[kaste]

I mean: running locally.

[kaste]

So here we are: packagecontrol/st_package_reviewer#52

[braver]

We've got a PR for a reviewer that works on packages. It's the best approach and apparently we are capable of such things.