Lazy loading fix

(Note: presumes #16 as a baseline.)

A user of this plugin in 1.509.1 reported some lazy-loading-related errors. Upon inspecting `build.xml` records, I found one which had

    <build class="matrix-build">
      …lots of stuff…
    </build>

rather than the usual

    <build class="matrix-build" reference="../../.."/>

The problem is akin to [JENKINS-17125](https://issues.jenkins-ci.org/browse/JENKINS-17125). Traditionally run actions stored a serializable reference to the `Run` which owned them, which XStream massaged into a symlink back to the root of the XML file. But if a `Run` is garbage collected and recreated with just the wrong timing, XStream may see the run field as having a distinct value from the owner, in which case it tries to reserialize the whole build…now symlinking the run action to itself:

    <hudson.plugins.jobConfigHistory.JobConfigBadgeAction reference="../../.."/>

The upshot is that keeping a nontransient run field is no longer reliable. The solution in 1.519+ is to implement the new `RunAction2` interface. This lets the run be reliably injected into the action, both when initially attached to the run, and when loaded later; no `<build>` element need be stored at all.

Unfortunately, there is no solution that I know of which will compile and link against earlier Jenkins releases: `RunAction` fails to pass the run in `onLoad`, which is when you must have it; and marking the run field `transient` not only prevents it from being _stored_, but it also prevents it from being _loaded_ from build records created before the fix, which means you cannot merely introduce a new persistent field based on e.g. `Run.getExternalizableId()` since it will be absent in old build records. JENKINS-17125 is marked `lts-candidate` so it is possible some 1.509.* update will have backported this crucial API.