Fixed a regression in 1.468 that broke LDAP

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)
creating an RC branch
Not exactly sure if these are truly needed, but J-on-J otherwise fails with compilation error.

It's apparently failing to properly deduce the JobT type. Making it explicit to avoid stretching the compiler
[maven-release-plugin] prepare release jenkins-1.469
[maven-release-plugin] prepare for next development iteration
updated changelog for release
releasing a new plugin parent POM
toward the next release
updated changelog as a part of the release
merged back the RC branch

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
Merge branch '1.469-out-of-cycle' into rc

Conflicts:
	changelog.html
Do not use & in url
Merge pull request #494 from lvotypko/url-without-ampersand

Do not use & in url
Thanks
Make it easier to see which characters will be encoded
Update doc for #494
Fix UtilTest and replace ampersand in method encode too
Mirrors appear to be serving botched 1.469 bits, so rolling forward.

I should have known better than reusing the version number. Apparently
the issue isn't just in Maven.
creating an RC branch
[maven-release-plugin] prepare release jenkins-1.470
[maven-release-plugin] prepare for next development iteration