Moving some DataConnector related classes over to -api

[Rod Widdowson]

You will have seen that I have just changed a whole bunch of classes in the idp-attribute-resolver-impl tree to add setters and
initialization.[1]

This has thrown up what I think is an oddity.  The RDBMS and LDAP documentation for "Externally (Spring) Defined Content" [2] [3]
refer to a three Interfaces (ExecutableSearchBuilder, MappingStrategy, Validator) .  These Interfaces are defined in the api tree.
But it turns out that the only classes which implement them in our distribution are defined in the impl tree which in turn means
that any configuration using the external spring resource will either be referencing the impl tree or hand-built code.

It also turns out that several of these classes follow the constructor-with-parameters paradigm, so I have duly changed them to
properties-and-Initialize (adding explicit initialialization tests if it seems appropriate).  However because of the risks of people
having stuff deployed (despite the impl status), I have left the constructors in place.

So.....  I would like to propose that I move these classes up into the api tree, whilst dropping the constructor variant.  We can
leave the constructor variant (as a deprecated, derived class) in the impl tree until V4.

This solves the dual problem of people pointing to impl classes in their configuration (eventually) and also means that going
forward the classes that we document for people fit into the properties/initialize paradigm.

[1] http://svn.shibboleth.net/view/java-identity-provider?rev=8444&view=rev
[2] https://wiki.shibboleth.net/confluence/display/IDP30/LDAPConnector#LDAPConnector-Externally(Spring)DefinedContent
[3]
https://wiki.shibboleth.net/confluence/display/IDP30/RelationalDatabaseConnector#RelationalDatabaseConnector-Externally(Spring)Defin
edContent

Rod