GH-1006 included QueryMappingConfiguration for all part tree queries

[mipo256]

Solving #1006 issue

To ease the review - actually, we already had the QueryMappingConfiguration applied for PartTree queries, but only for those that are declared in the repository and execute via PartTreeJdbcQuery#execute. For the predefined methods, that resolve into SimpleJdbcRepository methods we did not have QueryMappingConfiguration applied. So I've just covered this gap and added some tests to verify the expected behavior.

PS: For StringBasedJdbcQuery no changes required.

[mipo256]

Resolved the conflict after Iterable --> List return type change for DefaultDataAccessStrategy.
Kind reminder for the review @schauder :)

[schauder]

This PR fails DependencyTests.acrossModules. Could you please fix that?

[mipo256]

@schauder
It actually is a bit strange that we have the failure in archunit test for cycles between modules, since only spring-data-jdbc module was affected. I'll give it a look and report below.

[schauder]

There are components (e.g. repository, mapping that exist in various modules. You get circles among these when you have a dependency in one direction in one module (possibly relational or commons) but in the opposite direction in another module (e.g. jdbc)

[mipo256]

@schauder so, the dependency error was fixed. The solution was to move QueryMappingConfiguration from:

package org.springframework.data.jdbc.repository;

to

package org.springframework.data.jdbc.core.convert;

It seems to make sense, since the QueryMappingConfiguration is really a part of the core conversion mechanism, not really the repository package.

What are your thoughts on this? @schauder

[mp911de]

I updated our labels as this change is a breaking one by moving public types around.