[JENKINS-14814] "Ping-pong" builds store excessively large CauseAction

[FIXED JENKINS-7162] Add missing parameters as defaults when called from...

Add all the job defined Parameters to the ParameterAction using Defaults
if not passed via the command line.

Reduce duplicate entries for the same plugin and version when multiple update centers are publishing similar data

* The whole point of the rule is to allow access to the helper methods, so they need to be public

* also synced up with HudsonTestCase

For instance, use PegDown Formatter and enable SUPPRESS_ALL_HTML.

Based on the following IRC conversations:

 (04:02:29 PM) cliffano: my build slave is offline, "Disk space is too low. Only 0.331GB left on" , but the box has 5.5Gb free.. i've tried disabling the disk space checking, restarted both master and slave, that error message is still there
 (04:03:03 PM) rtyler: I've seen that a couple times, I think I just disconnected and reconnected the slave
 (04:03:47 PM) cliffano: no dice for me.. reconnected several times.. even tried deleting more stuffs to free up more space, still exactly the same error message
 (04:04:04 PM) rtyler: you could try reinstalling windows
 (04:04:06 PM) ***rtyler ducks
 (04:04:22 PM) cliffano: lol yea
 (04:04:49 PM) kohsuke: cliffano: you can force the recomputation of those metrics
 (04:04:56 PM) kohsuke: otherwise it's only once an hour
 (04:05:17 PM) rtyler: wait, you can force it?
 (04:05:37 PM) kohsuke: http://ci.jenkins-ci.org/computer/ "refresh status"
 (04:06:26 PM) rtyler: ah
 (04:07:25 PM) cliffano: kohsuke: thanks, that worked..
 (04:07:43 PM) kohsuke: although I expect that if you've been reconnecting that should be sufficient
 (04:08:08 PM) kohsuke: And I probably should also do that automatically when you reconfigure the column, threashold, etc
 (04:10:39 PM) cliffano: kohsuke: reconnecting didn't help somehow... i tried disconnecting from the UI, tried killing the process on the slave machine, restarted etc
 (04:10:56 PM) kohsuke: it's probably caching the value
 (04:12:16 PM) cliffano: kohsuke: does it cache in the filesystem? i restarted both master and slaves
 (04:13:09 PM) kohsuke: it's stored in Computer
 (04:13:11 PM) kohsuke: so I guess that explains
 (04:13:34 PM) kohsuke: let me clear this when a slave connects
 (04:16:23 PM) cliffano: kohsuke: thanks :)

[JENKINS-14495] Refined fix - needed to pull uniqueness check out of apply() fn in case we were being passed an Array of nodes.
Fixes test failures introduced by  dbb100da, and adds a test for it now that I know it can be done.

Unlike [JENKINS-14514] this is a true fix rather than a workaround (now removed), and is more general.
cjo9900 discovered that behaviors were being redundantly registered (as of 1.474 the monolithic JS is broken up);
this caused some behaviors to be run repeatedly on the same elements, breaking reasonable expectations of some behaviors.
The ideal fix would be to change Behavior.register to be idempotent: for example, key it by selector, then maintain a set of distinct behavior functions for each.
Unfortunately some adjuncts directly call Behavior.list.unshift, bypassing register(...), which would be tricky to intercept (would need to make a mock of Array).
The known one cases are in core, but it is possible plugin adjuncts do this too, in which case it would be incompatible to (say) change the Array<Map<String,Behavior>> to a Map<String,Array<Behavior>>.
Instead, permitting redundant registrations as before, and just silently skipping all but the first at runtime when applying behaviors.
Beware that since adjuncts are loaded from multiple places, different JS function objects are registered each time, so a naive set of behavior functions does not work;
have to identify functions by their toString in order to ensure that each is run only once.
(Currently once _per selector_, conceivably >1x per element; could if necessary be refined to make sure a given behavior is only run once on a given element during one call to applySubtree even if the element matches multiple selectors.)