API scanning improvement: hook up to PRs

[Cervator]

With #3253 merged we have the ApiSaver and ApiComparator that will write out and compare the changes made to engine API exposed to modules. If no changes have been made then the report has no entries and the change is of "patch" scope as per SemVer. Alternatively any minor or major changes detected will get logged in the report.

We should be able to hook that up for an initial API scan phase for new PRs now. But exactly how is still in question and sometime we should find out!

• The ApiWriter likely needs to be triggered during engine builds, with the API_file.txt artifact saved somewhere, like attached to the job in Jenkins
• On a PR build the ApiComparator needs to be run with the API_file.txt made available, which could again be done in Jenkins by copying in the attached artifact from the engine job to the root of the build workspace
• The report printed to the console by ApiComparator needs to be made available in connection to the PR. It could be sent to GitHub via @GooeyHub commenting with the details, but that could get spammy. Maybe we can issue a GitHub commit status and link to the details in Jenkins?
  • Advanced: make the commit status depend on whether the highest scope modified has been matched with a version increment since last release. So if a major change is detected the engine version should have its x value (from x.y.z) at least 1 greater than the previous release (the stable engine build in Jenkins / the master branch on GitHub). If the version increment hasn't been made yet count the status check as failed
• Maybe other creative options like using Probot or something
• Extra: if the PR includes new/updated engine libs (that are exposed to module land?) point that out as well (not done by the API scanning stuff)

This can probably be prototyped with a bit of effort (local Jenkins + a fork) but applying it to our official setup would take a bit of extra effort (admin access to Jenkins). It may get swept up in a major overhaul of job setup in Jenkins, however, as some of the new pipeline stuff has easier access to interact with GitHub.

Highly related: #3321 + #3322