JVSTM-lock-free (jvstm-2.0) integration in Deuce

* new package org.deuce.transform.jvstm including 3 additional
transformations to support the JVSTM: EnhanceTransactional,
EnhanceVBoxArrays and EnhanceStaticFields.

* new package org.deuce.transform.jvstm containing the new
Context and ContextDelegator implementations specific for the
JVSTM.

* Agent => now the Agent supports pre Enhancers, such as the
post Enhancers, but performing before the standard Deuce
instrumentation.

* Agent => new utility function loadClass to load the
auxiliary classes generated by the pre Enhancers e.g. EnhanceStaticFields.

* ExcludeIncludeStore => additional semantics for immutable classes,
distinct from the already existent Exclude. Immutable classes correspond
to instrumented classes containing a  transactional version of its methods
but without performing STM barriers. So, it allows that instances of these
classes may be invoked through transactional interfaces and avoid an
AbstractMethodError.

* The new semantics to immutable classes require minor changes to
DuplicateMethod and MethodTransformer classes.
JVSTM-lock-free (jvstm-2.0) integration in Deuce

Fixes to existent unit tests and include new unit tests specific for JVSTM.

* Minor change to existent unit tests, regarding the behavior of the
JVSTM, which does not store data in-place. So, if the assertion is made
getting transactional data without STM barriers, then it can get
inconsistent values. So it includes Atomic in the getters of the
transactional classes.

* New unit tests for the JVSTM: org.deuce.utest.jvstm,
org.deuce.utest.point.jvstm.units.gc and org.deuce.utest.point.jvstm.units.
JVSTM-lock-free (jvstm-2.0) integration in Deuce

* build.benchmarks.xml => include scripts for the configuration and
execution of the benchmarks with the JVSTM lock free and performing
capture analysis.

* To support Deuce transactional arrays with JVSTM we use the VBox
Array approach, meaning that arrays are wrapped inside a VBox.
However, when we access arrays from a non-transactional scope,
we are not using STM barriers and we cannot deal directly with VBoxes.
So, in this case we unwrap the encapsulated array from the VBox.
Yet, this solution has a limitation regarding multi-dimensional arrays,
due to the big overhead of unwrapping the encapsulated array from
the VBox.
So every time an unwrap operation occurs for a multidimensional array,
then it raises an exception alerting the end-user programmer. In this case,
one of the recommended workarounds is to access those arrays through
atomic indexers (which are performed within a transaction) and avoid
the unwrap. For this purpose we make some minor changes to some
benchmarks replacing the arrays access by atomic indexers.
Merge pull request #1 from fmcarvalho/feature/jvstm-lock-free

feature/jvstm-lock-free