Decouple JVM launching from Ant's Java task and allow clients to provide their own JVM launcher

The motivating use case: I would like to use Cargo to start containers from Eclipse. More importantly, I would like to attach the Eclipse debugger to the container/server JVM started by Cargo, to debug the servlets being deployed there. Technically, this boils down to use IVMRunner from the Eclipse JDT APIs. However, the JVM launching code in Cargo is currently hard-wired to use Ant's Java task.

In essence, the attached patch introduces the interface org.codehaus.cargo.container.spi.jvm.JvmLauncher. This interface is basically an abstraction of Ant's java task, allowing to provide alternative implementations (like the one from Eclipse). Subclasses of SpawnedContainer provide a setter that allows the client code to set the desired factory for the JvmLauncher instances being used. By default, a factory wrapping the Ant java task is used.

It's worth to note that Cargo forks JVMs for various tasks: starting a server, stopping it, pinging it, deploying into it, etc. For my case, I only want to provide a custom JvmLauncher when starting the server but stick with the Ant/default impl for all other JVMs. To enable this decision making, the JvmLauncherFactory is provided with a boolean to indicate whether a server JVM or some other client/utility JVM is launched. Instead of a boolean, an enum could have been used to denote the purpose of the launched JVM but I didn't see concrete use cases for such a fine-grained distinction so I went with the simple boolean.

This abstraction constitues a breaking change to the container SPI (which I hope is worth for Cargo 1.1) and the bulk of the changes in the patch deal with adjusting the existing container impls to the new SPI.

AFAICT, AntContainerExecutorThread is now only used from one package. If wanted, this class could be moved and even made package-private.