munkitools2 not pointing to stable about recipes

[timsutton]

Greg and I were hoping that this would be a good opportunity to use a GitHubReleasesInfoProvider processor I wrote some time ago, which was not fully-baked at the time to include in AutoPkg.

Just committed to an alternate munkitools-github branch in this repo, is an updated munkitools2 recipe that can selectively filter out the prereleases:
122c252

It uses a more capable and robust version of this GitHub processor. It also demonstrates filtering the release asset by a regex, which means the same processor could be used to get the 1.0 releases which came in a dmg.

However, because it replaces our previous custom processor, it doesn't currently let you override this same recipe to fetch from munkibuilds.org as the previous ones did.

I'd rather not break the existing recipes for everyone, as well as not require one to keep two different overrides with all the various displayname/description/etc. fields - you would wind up needing one for "stable" and one for the autobuilds, unless you just pick autobuilds and are careful about which releases you promote.

Perhaps it might be possible to keep the custom behavior by subclassing the GitHub processor and adding back in our hack we had for changing the behavior based on the URL, or at least just pass the url through if DOWNLOAD_URL was set by an override.

[timsutton]

Also, I should note that the GitHubReleasesInfoProcessor doesn't yet do sufficient validation of the keys in the JSON response.

While the few keys we use should always be there, there will also need to be an additional validation performed up front in case the API happens to be buggy at the time of an AutoPkg run.

[timsutton]

Recipes were split up into two, see for more discussion:

https://groups.google.com/d/topic/autopkg-discuss/j0nI3rYgEzQ/discussion