405876 : add support for web 3.1

Signed-off-by: Fred Bricon <fbricon@gmail.com>
405285 : make sure mavenProject instances are loaded

Signed-off-by: Fred Bricon <fbricon@gmail.com>
393801 : Change facet version delegates override all version delegates

Changes to be committed:
	modified:   plugin.xml
	modified:   src/org/eclipse/m2e/wtp/internal/facets/AppClientVersionChangeDelegate.java
	modified:   src/org/eclipse/m2e/wtp/internal/facets/EarVersionChangeDelegate.java
	modified:   src/org/eclipse/m2e/wtp/internal/facets/NoOpVersionChangeDelegate.java
	modified:   src/org/eclipse/m2e/wtp/internal/facets/WarVersionChangeDelegate.java

- I wrote 100 % of the code
- I have the right to contribute the code to Eclipse
- I have updated the header
393801 : renamed *VersionChangeDelegate to *VersionChangeListener

Signed-off-by: Fred Bricon <fbricon@gmail.com>
Move JAR renaming folder, improve JAR locking issues, fix JAR update policy.

m2e-wtp copies JARs from the Maven dependency into a folder so that it can
rename the file name in the process of doing this.  This is a workaround due
to limited API in WTP and Server Runtimes for doing this.

Previously the working folder was the target/*.jar this was unfortunate since
Maven itself places output JARs there and the files were not marked as hidden
or derived.  By moving the files to target/m2e-wtp/jar-rename/*.jar now the
Maven output artifacts to not get lost in the noise of m2e-wtp performing
this copy.  As a side effect the target/m2e-wtp folder is marked as both
Hidden and Derived this appears to have resolve the Windows platform JAR
locking issue, where some other part of Eclipse would open a file handle
on these new ClassPath JAR entries.  This JAR locking causes a "mvn clean"
to fail as the target/ folder could not be deleted without an Eclipse restart.

Also I have modified the policy on when a JAR copied.  Previously if a JAR
by the same filename existed then it would never update it with a new
(possibly different copy).  There was also no mechanism (within Eclipse) to
clean/delete the files forcing it to be updated.  The problematic scenario
can be desrcibed as when you have 'Disabled Workspace Resolution' so your
project obtains a SNAPSHOT version from a repository.  Since the SNAPSHOT
maybe updated many times under the same filename it was possible for the
newer copy to never get published to the server runtime because a JAR of
the same name already existed.

I confirm that this contribution is soley my own work, that the contribution
is licensed under the project license (currently the Eclipse Public License
v1.0).

  * I wrote 100 % of the code
  * I have the right to contribute the code to Eclipse
  * I have updated the header