Fix UtilTest and replace ampersand in method encode too
Thanks !

Conflicts:
	changelog.html

Conflicts:
	changelog.html

I should have known better than reusing the version number. Apparently
the issue isn't just in Maven.

Do not use & in url
Thanks

Conflicts:
	changelog.html

Conflicts:
	changelog.html
	cli/pom.xml
	core/pom.xml
	maven-plugin/pom.xml
	pom.xml
	test/pom.xml
	ui-samples-plugin/pom.xml
	war/pom.xml

It's apparently failing to properly deduce the JobT type. Making it explicit to avoid stretching the compiler

Stack trace:

org.jvnet.hudson.reactor.ReactorException: java.lang.IllegalAccessError: tried to access method hudson.security.SecurityRealm.findBean(Ljava/lang/Class;Lorg/springframework/context/ApplicationContext;)Ljava/lang/Object; from class hudson.security.LDAPSecurityRealm$LDAPUserDetailsService
  at org.jvnet.hudson.reactor.Reactor.execute(Reactor.java:246)
  at jenkins.InitReactorRunner.run(InitReactorRunner.java:43)
  at jenkins.model.Jenkins.executeReactor(Jenkins.java:885)
  at jenkins.model.Jenkins.<init>(Jenkins.java:790)
  at hudson.model.Hudson.<init>(Hudson.java:81)
  at hudson.model.Hudson.<init>(Hudson.java:77)
  at hudson.WebAppMain$2.run(WebAppMain.java:217)
Caused by: java.lang.IllegalAccessError: tried to access method hudson.security.SecurityRealm.findBean(Ljava/lang/Class;Lorg/springframework/context/ApplicationContext;)Ljava/lang/Object; from class hudson.security.LDAPSecurityRealm$LDAPUserDetailsService
  at hudson.security.LDAPSecurityRealm$LDAPUserDetailsService.<init>(LDAPSecurityRealm.java:419)
  at hudson.security.LDAPSecurityRealm.createSecurityComponents(LDAPSecurityRealm.java:369)
  at hudson.security.SecurityRealm.getSecurityComponents(SecurityRealm.java:398)
  at hudson.security.HudsonFilter.reset(HudsonFilter.java:134)
  at jenkins.model.Jenkins.setSecurityRealm(Jenkins.java:1960)
  at jenkins.model.Jenkins$17.run(Jenkins.java:2524)
  at org.jvnet.hudson.reactor.TaskGraphBuilder$TaskImpl.run(TaskGraphBuilder.java:146)
  at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:259)
  at jenkins.model.Jenkins$7.runTask(Jenkins.java:874)
  at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:187)
  at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:94)
  at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
  at java.lang.Thread.run(Thread.java:680)

I thought about this and decided that the best way to incorporate this
expansion of the abstraction is to think of it as a re-configuration of
project right before the build.

This resolves my concern with the previous change of calling expensive
rebuildConfigurations() from every getActiveConfigurations() call (and
getter shouldn't have a side-effect, right?)

Also, in this way, Axis gets a reference to MatrixBuildExecution, so it
makes it more explicit that the Axis can update values based on the
current build.

Sometimes there's the need to change the value of an axis right when the build starts.
I did this adding a couple of methods to Axis and letting MatrixBuild use them.
It should all be backwards compatible.