[FIXED JENKINS-25074] Make sure to call Job.getBuildHealthReports just once per t:buildHealth render.

Based on the reaction to these issues and JENKINS-24514, I'm partially
reverting the original change, and bringing the umask default back to
022.

The configurable option does enable the user to choose a different
umask, so I think I can still claim that JENKINS-24514 is addressed.

[FIXED JENKINS-24703] Do not set any colors for input elements

This version includes a change from christ66 in
https://github.com/stapler/stapler/pull/40

Turns out there was a security advisory posted on Ant 1.8.3
(http://ant.apache.org/security.html) though the affected code is not
used in Jenkins.

Reference: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2098

Convert AbstractProject to better utilize structure form submission.

For example, the following should not cause Run.onLoad itself to fail:
java.lang.NullPointerException
	at org.jenkinsci.plugins.workflow.steps.input.InputAction.onLoad(InputAction.java:29)
	at hudson.model.Run.onLoad(Run.java:342)
	at org.jenkinsci.plugins.workflow.job.WorkflowRun.onLoad(WorkflowRun.java:332)

java.lang.RuntimeException: Unable to copy /…/jobs/…/config.xml
	at hudson.plugins.jobConfigHistory.FileHistoryDao.createNewHistoryEntryAndCopyConfig(FileHistoryDao.java:252)
	at hudson.plugins.jobConfigHistory.FileHistoryDao.createNewItem(FileHistoryDao.java:238)
	at hudson.plugins.jobConfigHistory.JobConfigHistoryJobListener.onCreated(JobConfigHistoryJobListener.java:31)
	at hudson.model.listeners.ItemListener.fireOnCreated(ItemListener.java:161)
	at jenkins.model.Jenkins.putItem(Jenkins.java:2483)
	at …
Caused by: java.io.FileNotFoundException: /…/jobs/…/config.xml (No such file or directory)
	at java.io.FileInputStream.open(Native Method)
	at java.io.FileInputStream.<init>(FileInputStream.java:120)
	at hudson.plugins.jobConfigHistory.FileHistoryDao.copyConfigFile(FileHistoryDao.java:178)
	at hudson.plugins.jobConfigHistory.FileHistoryDao.createNewHistoryEntryAndCopyConfig(FileHistoryDao.java:250)
	... 108 more

[FIXED JENKINS-23020 JENKINS-23942] Convert the queue's cancel shutdown to POST

Both 0 and 1 are used to indicate some kind of success (the latter when Jenkins doesn't need to be started because it was already running), so we need to return 2.

java.lang.NullPointerException
	at hudson.model.User.idStrategy(User.java:140)
	at hudson.model.User.getOrCreate(User.java:373)
	at hudson.model.User.get(User.java:366)
	at hudson.model.User.get(User.java:331)
	at hudson.model.User.get(User.java:441)
	at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.getAuthentication(CpsFlowExecution.java:614)
	at org.jenkinsci.plugins.workflow.cps.CpsVmThread.run(CpsVmThread.java:20)

Conflicts:
	.idea/encodings.xml
	core/pom.xml
	pom.xml
	test/src/test/java/hudson/tasks/junit/CaseResultTest.java

Integrated the change

By converting several optionalBlock entries to use inline="true", we convert the submitted JSON from:
   "hasPropertyFoo": {
     "propertyFoo": "value"
   },

which is a somewhat unnatural naming scheme, to:
   "hasPropertyFoo": true,
   "propertyFoo": "value",

This enables us to use the pattern:
   if(json.optBoolean("hasPropertyFoo", json.has("propertyFoo"))) {
     ...
   }

To permit either of the following as JSON blobs, for specifying a value for "propertyFoo":
1) "hasPropertyFoo": true,            # What comes through from jelly
   "propertyFoo": "value",

2) "propertyFoo": "value",

It also allows any of the following as JSON blobs, for NOT specifying a value for "propertyFoo":
3) "hasPropertyFoo": false,           # What comes through from jelly
   "propertyFoo": "value",

4) "hasPropertyFoo": false,

5) (nothing specified)

NOTE: The main interest in flexibility in what JSON comes through is in support of: https://wiki.jenkins-ci.org/display/JENKINS/YAML+Project+Plugin, this is also the purpose of the couple renames that are mixed in with this.

Add getFieldOrder() methods.

Switch to using inline optionalBlock for several AbstractProject checkboxes so that we are passed a boolean, instead of either null or {}.

NOTE: The discrepancy between inline-optionalBlock and f:entry/f:checkbox is the text alignment, which optionalBlock keeps consistent with other elements (and what is done for these today).