both these files will be replaced with new files from https://github.com/nlebas/tiles-request/commit/16de83499bd335832c9c1cac3ce466fd880c7942
spring integration

Conflicts:

	pom.xml
	tiles-request-portlet-wildcard/src/test/java/org/apache/tiles/request/portlet/wildcard/WildcardPortletApplicationContextTest.java
	tiles-request-servlet-wildcard/src/test/java/org/apache/tiles/request/servlet/wildcard/WildcardServletApplicationContextTest.java
    SPR-8825 - Tiles-3 support

Second attempt.  fetched+cherry-picked https://github.com/nlebas/tiles-request/commit/16de83499bd335832c9c1cac3ce466fd880c7942
 This is a cleaner implementation focused on using tiles-request (a spinoff abstraction from Tiles-3)
 see "TREQ-12 - Spring integration" https://issues.apache.org/jira/browse/TREQ-12

Changes made to nlebas's changeset:
 - refactor package names appropriate for spring,
 - use spring-test mocks for servletContext, request, response (easier stubbing),
 - upgrade to tiles-request-1.0.1 and tiles-3.0.1 (both will be made public shortly),
 - add RendererView.exposeForwardAttributes,  needed when handling forwarding requests, see SPR-6623,
 - SpringApplicationContext is now expected to be a spring bean, direct instantiations removed,

 - SpringApplicationContext delegates scope and context methods to an embedded ServletApplicationContext,
      required for the DispatchRenderer to work,
      all spring beans are no longer available through application scope (i didn't think exposing this into the view layer was wise anyway),

 - SpringRequest extends DispatchRequestWrapper, required to work,

 - RendererViewResolver.renderer defaults to a DefinitionRenderer,
      this convention over configuration simplifies a lot
      but introduces the tiles framework code so that it's no longer a clean tiles-request implementation,
      i don't think this is a problem as TilesConfigurer in the same package is all about tiles framework code already,
      (maybe seperate packages could be used ".tiles3" and ".tiles3.request" where the clean tiles-request code can be moved to?)

 - keep TilesConfigurer
   -- provides compatibility with existing spring+tiles apps,
   -- provides tiles java code configuration approach (ie by implementing your own TilesInitializer),
   -- a spring xml configuration approach is coming latter, see "TILES-545 - spring-based configuration",
   -- the SpringApplicationContext spring bean can be looked up and used as the prelimaryContext,
   -- use PropertyAccessorFactory to lookup localeResolver rather than raw reflection code,
   -- directly use JspFactory.getDefaultFactory() instead of going via JspEvaluatorFactoryFactory, also default instantiate factory for jsp-2.1,

Not added:
 - TilesView could benefit from wrapping its call to container.render(..) with container.startContext(..) and container.endContext(..)
      This was a fix to address TILES-544.
      but RendererView calls renderer.render(..) instead of container.render(..)
      so i'm uncertain if startContext and endContext is required. it would be nice if it were not as it doesn't belong in tiles-request-* code.

This attempt also properly uses and tests the tiles code in the webapp. Previously the webapp was just directly calling the jsp.