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