BATCH-2248: Fixes for Ldif reader tests

Conflicts:
	spring-batch-core-tests/src/test/java/org/springframework/batch/core/test/ldif/LdifReaderTests.java
	spring-batch-core-tests/src/test/java/org/springframework/batch/core/test/ldif/MappingLdifReaderTests.java
	spring-batch-core-tests/src/test/resources/applicationContext-test1.xml
	spring-batch-core-tests/src/test/resources/applicationContext-test2.xml
Change prefetch on jms tests to 0 and add @DirtiesContext to tests

With the upgrade to ActiveMQ 5.9.0 as part of Spring IO, ActiveMQ's
prefetch behavior changed.  With each call to
JmsTemplate#receiveAndConvert, the template creates a new consumer.  In
these tests, the first call created a consumer which prefetched all the
test messages on the queue, leaving them unavailable for the second
consumer the JmsTemplate created.  By setting prefetch to 0, the
messages are now available for the subsequent
JmsTemplate#receiveAndConvert calls.  This addresses BATCH-2248.

Conflicts:
	spring-batch-infrastructure-tests/src/test/java/org/springframework/batch/repeat/jms/SynchronousTests.java
[artifactory-release] Next development version
Filter out duplicate ApplicationContextAwareProcessors in parent/child
contexts scenarios

AbstractApplicationContextFactory, when configuring a child context,
copies all of the BeanPostProcessors from the parent to the child.
Normally this is a good thing.  However, in the case of teh
ApplicationContextAwareProcessor, the child context ends up with two
instances, one for the parent context and one for the child context.
This brings two issues to light:
  1. Unknown which context is being injected - On beans implementing
ApplicationContextAware, it can't be determined which context (the
parent or the child) will be injected since both BPPs will be called in
an indeterimant order.
 2. Errors occur with ApplicationObjectSupport - If the child context
contains a bean that extends ApplicationObjectSupport, when the second
ApplicationContextAwareProcessor is called, the bean will throw an
exception since it is only allowed to be initialized with one
application context.

This fix adds additional logic to remove the
ApplicationContextAwareProcessor from the parent context before adding
all the BPPs to the child.

This fix addresses BATCH-2319.
Add reflection check for Spring 4.1 in Mail Writer tests

As part of the Spring Framework 4.1 updates, the send methods on both
MailSender#send and JavaMailSender#send were converted from taking an
array to vargs.  This commit adds a reflection check to determine which
version of Spring it's being built against and uses the apropriate
mocking checks in these tests based on that check.
Changed repository references from http to https
Fixed manual wiring of JsrJobOperator

While the JSR-352 provides only one way to access the JobOperator
(BatchRuntime.getJobOperator()), it is useful for testing and embedding
to be able to wire your own JsrJobOperator instance.  This commit
addresses previous issues with using the constructor that provided that
functionality.

Note: This is a breaking change in that there is a new parameter on the
non-default constructor (adding a PlatformTransactionManager reference).
Users using the JsrJobOperator through the BatchRuntime as previously
mentioned should not be impacted.  Since this is the *only* method
perscribed by the JSR to consume that class, it is not expected to have
a large impact.

This fix partially addresses BATCH-2290.
Add job repository polling option to MessageChannelPartitionHandler

When using remote partitioning, each slave worker persists it's current
status in the same job repsository that the master uses.  Because of
this, there is no hard need for the master to wait for each worker to
send a formal response once it's work is complete.  Instead, the master
(at the cost of polling a db periodically) can determine if the workers
are done by looking up each partition's status in the job repository.
This commit removes the requirement for a reply channel and implements
the polling of the job repository to determine if the workers are done.

BATCH-2332
Add ability to override JSR-352 baseContext.xml

While existing functionality provided the ability to override the
components provided in the baseContext.xml (as required for JSR-352
functionality) at a job by job level, this commit allows a user to
specify a base context for all of the JSR-352 based jobs within a JVM.
To set the location of the custom base context, a JVM property
JSR-352-BASE-CONTEXT should be set.

BATCH-2290
Make use of current working dir explicit for compatibility with H2 1.4

H2 1.4 requires that file paths that are relative to the current
working directory declare this explicitly, i.e. the path
file:/some-dir must now be file:./some-dir.

This commit updates DatabaseTypeIntegrationTests to meet the
above-described requirement, thereby allowing the tests to pass when
run against H2 1.4.x.
Removing references to AbstractJobTests which has been deprecated in favor of JobLauncherTestUtils