Unlike the bug I originally reproduced, in which the parent had some builds
but the context in which the new build was scheduled omits a parent,
this seems to be due to a case in which there is no build record at all for the parent.
No idea how that could happen (getLastBuild should return even a running, failed, or aborted build),
but @treydock reports a stack trace in 1.509.2 which implies this.
So fixing null safety; will not prevent an exception but will report it more gracefully.

Going back in browser history can reset configuration form to the *previous* state,
not what was just saved! (In the case of lazily inserted form elements.)
Thus clicking Save from that page would actually revert your recent changes.
For now, just omitting the button; could make it go back to index or configuration pages,
but there are already links for this.

Conflicts:
	core/src/main/java/hudson/model/AbstractProject.java

This helps a lot when mocking AbstractProject in unit tests, because so I don't have to suppress the constructor with PowerMockito

[JENKINS-14585] core side fix for: claim-plugin cannot claim broken tests in maven jobs

The earlier fix by @ssogabe broke the test. This fix corrects the
problem properly.

The reason this error happens with some plugins is that if there's an
input field whose name is "on", then even after prototype.js extends
an element object, "form.on" will refer to the input element, not the
prototype.js function to add an event handler.

(cherry picked from commit d8f74cf8)

If every node is restricted to tied jobs only, Matrix build jobs can never start

- Fixes a regression in core where the display name clear on copy was triggering a save
- More than one way to do this, could also have used the marker interface approach
  This route seems slightly less fragile, though people could still add ItemListeners
  with order == -Double.MAX_VALUE which would then introduce intdeterminism.
  A marker interface would remove that indeterminism as the onCopyComplete method would
  be only called on the Job as the last method... but it could be hard to
  ensure that all ItemGroupMixin's respect the calling of onCopyComplete contract
  hence this approach seems better to me for that reason

- The caller is no longer responsible as the listener is actually invoked from the method

Use DescribableList to handle the copy-on-write semantics correctly. The vector class just doesn't cut it, and we've been setting a new value to this field, which will violates all sorts of the concurrent programming practice.

This change has the nice side effect of removing {{class="vector"}} from the persisted XML. A test is added to make sure we can still read back such an XML.