New gracefulExit MOJO option to exit the Juliac MOJO without throwing an exception even if errors are reported.

This feature originates from a discussion with Nicolas Salatge and Julien Lesbegueries from Petals Link, who want to be able to run commands like <code>mvn eclipse:eclipse</code> even if this plugin reports an error. The issue is not specific to this plugin but to the fact that, in most cases, this plugin is associated with the <code>generate-sources</code> lifecycle phase which is run when commands like <code>mvn eclipse:eclipse</code> are invoked.

to determine the Java package where the WSDL service class is defined.
This issue appeared with the ADT galaxy's dealer network example where some WSDL <service> are 
not declared in the same namespace than their related WSDL <portType> declaration.

Change the API of the parser service to include contextual information. This contextual information is needed by Fractal ADL. The idea is to let the component optimization level source code generator depends only on juliac-core and not of some Fractal ADL plugin specific feature. This generator should be reused by Tinfi for supporting component-based membranes defined with the SCA Assembly Language.

Policy change for associations between bytecode and source interceptor generators (for class and source code): enable retrieving the class name of the generator from the .cfg file directly even if no association has been previously defined.
Used in Tinfi for specifying code generators directly in the .cfg file.

New --iclassgs for specifying association between bytecode interceptor class generator and source code ones.
The same for MOJO XML tags, i.e. for <igs> renamed to <icodegs> and new <iclassgs> tag.

Retrieve interceptor class generator information from julia.cfg. Store in JuliacConfig associations between bytecode interceptor class generator and source ones.

Move module tests-tools from examples/advanced/ to extension/ and used it for the tests of module juliac-core.

Deprecated. As far as I know, solution never really tested and not used. Furthermore, such a feature would now take different paths now (see Tinfi and multi annotation set support.)

Commented UPnP test cases because they require that the underlying OS supports multicast and this is not the case of the OW2 Bamboo machine.

Refactoring.