Reference to builds causes internal inconsistencies and performance issues

Each MultiJob build contains serialized references to subjob's builds. This is very, very evil because:

• the XML of the build is unnecessarily large, as it contains the complete downstream builds
• loading the build effectively reloads all downstream builds
• ... but from a different source, so you might end up with different Build objects for the same build, which leads to one of them having a parent of null, leading to wierd NPEs down the line.

Luckily, this is easy to fix:

• Make the build field transient and non-final.
• Add a final String buildid.
• On construction, set buildid to build.getExternalizableId() unless it is null.
• In the getBuild() method, first check if build is null, but buildid is not (which is the case after deserialization). Get Run.fromExternalizableId(buildid), if it is an AbstractBuild, assign to build.
• Don't do this at deserialization time. This will cause issues if relevant builds have not been fully loaded yet.

While we're at it, make the MultiJobAction in MultiJobBuilder a static class. Otherwise, the surrounding class is also serialized into the XML, and a surrounding object is recreated that is not even used and cannot be accessed.