fix hub to make most client calls without waiting for HTTP response

Change the XmlRpcCallableClient implementation used by the hub to use
callAndForget rather than callAndWait.  The effect of this is that
hub call() and callAll() invocations do not wait for the completion
of the XML-RPC call (the HTTP response) before returning from the
client's call.

This sounds like sense, and it's the way it used to happen in JSAMP 1.1
(before Feb 14, 2011, commit 764a76e39).  I made the change from
callAndForget to callAndWait that time because it was causing trouble
with hub shutdown during JVM shutdown - shutdown messages to the
clients were not getting completed.  However, with the improved
JVM shutdown management that is now in place, I think it the current
change may manage to work OK in both cases.  We'll see.
work round JNLP shutdown classloading bug

Laurent Bourges reports the following stack trace during shutdown
when running a JNLP-invoked application with JSAMP and the web hub:

  14:26:21.650 INFO  [AWT-EventQueue-2] fr.jmmc - Exiting with status code '0'.
  WARNING: Shutdown hook failure: java.lang.IllegalStateException: zip file closed
  java.lang.IllegalStateException: zip file closed
      at java.util.zip.ZipFile.ensureOpen(ZipFile.java:634)
      at java.util.zip.ZipFile.getEntry(ZipFile.java:305)
      at java.util.jar.JarFile.getEntry(JarFile.java:227)
      at com.sun.deploy.cache.CachedJarFile.getEntry(Unknown Source)
      at java.util.jar.JarFile.getJarEntry(JarFile.java:210)
      at com.sun.deploy.security.DeployURLClassPath$JarLoader.getResource(Unknown Source)
      at com.sun.deploy.security.DeployURLClassPath.getResource(Unknown Source)
      at java.net.URLClassLoader$1.run(URLClassLoader.java:358)
      at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
      at java.security.AccessController.doPrivileged(Native Method)
      at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
      at com.sun.jnlp.JNLPClassLoader.findClass(Unknown Source)
      at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
      at java.lang.ClassLoader.loadClass(ClassLoader.java:412)
      at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
      at org.astrogrid.samp.web.WebHubProfile.stop(WebHubProfile.java:117)
      at org.astrogrid.samp.hub.Hub.shutdown(Hub.java:116)
      at org.astrogrid.samp.hub.Hub$4.run(Hub.java:526)
      at org.astrogrid.samp.ShutdownManager.doCleanup(ShutdownManager.java:92)

This can apparently be prevented by constructing certain Runnables for
execution on the EDT earlier in the object's lifecycle.  The bug is
fairly harmless but annoying; this fix (also supplied by Laurent, though
with stylistic adjustments from MBT) is completely harmless and
reduces the annoyance.
set Standard Profile samp.profile.version to 1.3

The version number written to the Standard Profile lockfile was wrong.
avoid a couple of null pointer exceptions

Laurent Bourges reports that NPEs can result in CallableClientServer
under some circumstances.  This is possibly symptomatic of a race
condition that should be fixed elsewhere, but this fix is certainly
harmless.
prepare for release 1.3.5
fix filter editing of downloads site page

It was previously done in a pre-maven3 way.
The way it's done now is not nice, since it requires to write the
version number twice into the pom.xml file and update them by hand
in step.  There is probably a better way.
add build note to pom