Java EE and WildFly Integration

replaced jaxb with stax parsing code and associated object model.
replaced the use of scanotation with CDI.
created a set of SPI to abstract out environment-dependent services (e.g., transaction, concurrency, classloader, batch configuration, etc)

update jberet-core version in wildfly to be the next jberet version that includes the above new features and changes.
package names have changed, added or removed in JBeret, so need to update jberet package names in wildfly/build/pom.xml.
remove scanotation dependency from wildfly/pom.xml, wildfly/batch, wildfly/build, wildfly/build/src/main/resources.
the dependency on transaction implementation libraries (arjuna and narayana-jta) have been moved from jberet-core to jberet-se. So they should be completely removed from wildfly batch integration code.
transitive dependencies of jberet-core have been declared as optional in project jberet, so no need to exclude them in wildfly/pom.xml.
implement SPI (jberet-core/src/main/java/org/jberet/spi) for Java EE environment. The Java SE impls are in jberet-se/src/main/java/org/jberet/se and jberet-se/src/main/resources/META-INF/services/org.jberet.spi.BatchEnvironment
run CTS batch tests (src/com/ibm/jbatch/tck/tests). During first batch integration, we have run majority of these tests and many related issues already been addressed.

Umbrella issue for batch integration: https://issues.jboss.org/browse/WFLY-508
The tracking issue for running CTS batch tests: https://issues.jboss.org/browse/WFLY-1588
CTS batch tests bugs against Oracle:
- CTS-114 (Batch API test archives include beans.xml inferring a dependency on CDI not required by the Specification)
- CTS-115 (Batch TCK test archives include default TCK SPI implementation preventing us to use our own)
- CTS-116 (JDBC resource reference not declared in Batch test archives which is not portable)

Provide feedback