BATCH-2294: Don't replace my PlatformTransactionManager with a new one

[elreydetodo]

For some reason DefaultBatchConfigurer decides that you can't possibly
already have a PlatformTransactionManager and makes a new one for you.
Because of the way Spring's bean factory works, this new one is
sometimes created after the one you actually wanted, and it replaces
the real one in your application with a lame one that is useless.

This patch changes the implementation of DefaultBatchConfigurer so it
tries to autowire an existing bean and only makes a new one if one
doesn't exist already.

[elreydetodo]

This PR tries to fix the same issue as #415, which has merge conflicts. I took what seems like the simpler route.

I was unsure how to create a test for this situation. I'm open to suggestions. I'm also happy to make adjustments to the way I fixed it if anyone has a better suggestion.

[elreydetodo]

This formatting seems inconsistent with the Spring Framework Code Style. There should be a space between "if" and the paren. I mimicked what was already in the file because I felt it would be weird to mix the style within a single file. I'm happy to fix the formatting if you'd like me to, but I want to make sure the approach I took is acceptable before I go to that effort.

[elreydetodo]

@mminella can you take a look at this PR? It's doing the same thing as #415, but it doesn't have a merge conflict and it doesn't add that getter you didn't like.

[mminella]

@elreydetodo We actually reviewed these PRs internally yesterday. We liked the structure of the if statements in the init method better in #415 but we liked your logging additions. If you want to apply the changes he made to your PR and add a test, we'd be happy to merge it. cc: @benas

[fmbenhassine]

I was unsure how to create a test for this situation.

I wrote a test suite here: fmbenhassine@b6fa592

While testing this PR, I found a couple of issues:

• When I specify a data source but not a transaction manager, I was expecting a DataSourceTransactionManager to be used but it is not the case (this test is failing)
• When I don't specify a data source and no transaction manager, I'm expecting a ResourcelessTransactionManager to be used but this is not the case (this test is failing)

Those tests are failing because of the following sequence:

1. SimpleBatchConfiguration is loaded, the 5 @Bean annotated methods are invoked and beans are added to the application context. One of them is the transaction manager which is a lazy proxy with null reference.
2. The setter DefaultBatchConfigurer#setTransactionManager is invoked and gets injected the transaction manager bean created in 1)
3. The DefaultBatchConfigurer#initialize is invoked where the condition if(this.transactionManager == null) is never true.

As mentioned in #415, I think we should not try to autowire the transaction manager. If the user wants a custom transaction manager, he has to provide a custom BatchConfigurer (subclassing DefaultBatchConfigurer and overriding the getter should be sufficient). Note that this is possible if we use the getter in initialize and createJobRepository methods (this approach is tested here: fmbenhassine@b6fa592, and all tests are passing (except the ones that are ignored because we don't want to address them)).

[mminella]

Based on the comments @benas made as well as the PR he submitted to address this issue, I'm closing this PR. #634 should address the functionality discussed in this issue. Thank you for the contribution!