Keycloak Multi Tenants - First draft

This is a first draft for a proposal on the implementation of multi tenancy for Keycloak and is intended only to start a discussion on this feature. 

This is based on the assumption that Keycloak will defer the resolution of the realm to the application, if the application so chooses. As such, the incoming request has a more important role as before for this. Thus, the HttpFacade.Request is now a dependency on some other places. 

Some notes:
- All tests passes (ie: no regressions, it seems), but no new tests were added (will be, if this is the right direction for this feature)
- Perhaps the KeycloakDeployment should be renamed or split. One part of it could be about the "keycloak server", and the second part could be about the "realm". This is more evident with the new clustering support
- Talking about the clustering support: it was committed after I started working on this PoC, so, I haven't thought about it when coding and just fixed the merge conflicts. 
- The basic idea is that if an application defines "keycloak.config.resolver" as a context param, Keycloak will defer the resolution of KeycloakDeployment to the class specified on this property. It provides the HttpFacade.Request to this resolver. If this property is not available, the previous behavior takes place (ie: loading the KeycloakDeployment based on WEB-INF/keycloak.json). 
- I have tested this Wildfly/Undertow adapter deployed on Wildfly 8.1.0.Final and running the application at  https://github.com/jpkrohling/keycloak-tenants-poc against a 1.0.1.Final server.