DATAJPA-564 - Support for SpEL based parameter expressions in String based queries.

We now support the discovery and dynamic registration of SpEL expression parameters in String based queries. Introduced an ExpressionEvaluationContextProvider that provides access to
a potentially shared SpEL EvaluationContext that is defined in the application context. This allow shared spring beans to be used within query expressions.
The SpEL expressions are evaluated in org.springframework.data.jpa.repository.query.SpelExpressionStringQueryParameterBinder.potentiallyBindSyntheticParameters(T) by using a hierarchal EvaluationContext with the RootObject set to the current method arguments.
We enhanced the parsing of ParameterBindings in ParameterBindingParser to support "synthetic" Parameters like SpEL expressions that should be evaluated at query time.

This feature works with Hibernate, EclipseLink as well as OpenJPA.

We currently support those variants:
Indexed parameter:
@Query("select c from Customer c where c.firstname = ?1 and c.attribute1 like ?#{[0] + ' ' + [1]})
To determine the index for the expression parameter we determine the max parameter index present and use that as an offset to generate appropriate parameter indices.

Named parameter:
@Query("select c from Customer c where c.firstname = :firstname and c.attribute1 like :#{[0] + ' ' + [1]})
whereby we generate a name like __$synthetic$__0 for SpEL parameter expression.
DATAJPA-564 - Add support for dynamically evaluating SpEL expressions in derived queries.

We now support the dynamic discovery and binding of SpEL Expression parameters in query derivation. Introduced ExpressionAwareParameterBinder for generic SpEL expression evaluation support.
DATAJPA-564 - More robust handling of SpEL expressions in String queries.

We now treat the result of the SpEL expression evaluation as Object instead of just String in ExpressionAwareParameterBinder. We now prefer index based parameter binding over named parameter binding iff only SpEL expression parameters are present. We now make named parameters available as variables in SpEL expressions.
DATAJPA-564 - Expose invocation arguments as well as delegate root object properties via root expressions.

We now use the rootObject of the delegates context as the rootObject for the expression evaluation as well as the arguments of the current method call are available via positional indices as well via the special variable called "args".

Added minimalistic Security Context infrastructure that mimics that from Spring Security to ease testing.

Referenced appropriate JIRA issues.
DATAJPA-564 - Removed support for SpEL expressions in derived queries.

We came to the conclusion that allowing SpEL expressions as parameters in derived queries would create incentives for users to mess with the low-level Expressions API in high level user code. Therefore we decided to remove this feature - for now.
DATAJPA-564 - Renamed ExpressionEvaluationContextProvider to EvaluationContextProvided.
DATAJPA-564 - Added EvaluationContextExtension SPI for configuring extensions to the EvaluationContext.
DATAJPA-564 - Extracted SPI into Spring Data Commons.
DATAJPA-564 - Allow SpEL expressions to be the only consumer of query method parameters.

We now allow the parameters of query methods to also be exclusively consumed by expressions within a given query string. Previously this wasn't possible due to to strict checks for parameter usage in JpaQueryMethod.
Relax check for query param usage in JpaQueryMethod.
DATAJPA-564 - Allow SpEL expressions to be the only consumer of query method parameters.

We now allow the parameters of query methods to also be exclusively consumed by expressions within a given query string. Previously this wasn't possible due to to strict checks for parameter usage in JpaQueryMethod.
Relax check for query param usage in JpaQueryMethod.
Enabled HSQLDB support for oracle syntax to be able to use the ROWNUM() function for pagination.
DATAJPA-564 - Allow SpEL expressions to be the only consumer of query method parameters.

Since eclipselink doesn't reliably report whether a given query contains parameter we try to set query-parameters via brute force in SESQPB.
DATAJPA-564 - Polishing of SpEL integration test cases.