Review for xd on yarn (do not merge)

This is a change set to be base for discussion happening later. Commenting later and only on higher level concepts because this is not yet functionally complete.

- PollingTaskSupport in spring-xd-yarn/yarn-app-xd will go away. Jar from that project also goes away if I don't come up with anything which should be shared between yarn-app-xd-appmaster and yarn-app-xd-container
- spring-xd-shell should not depend on spring-xd-dirt, I'd like to get access to application.yml from shell order to use Boot configuration properties. Maybe we could move application.yml out from spring-xd-dirt?
- Been trying to do the build so that relevant libs are only in a classpath if supported distros(hadoop22 for now) are activated. Otherwise we get into too many class loading issues.
- I'm a little nervous about how I build/package the xd application used in yarn. Bundling this package with XD distribution is easy but then it makes a whole distribution bigger. Should we just upload that to repository just like xd distribution, and then download/cache it when user is trying to use/deploy it from a shell?
- We should have a common story of how the configuration is done. "spring config set" looks a bit sketchy and overlaps with "hadoop config"
- Sinks and sources using hdfs doesn't work because properties are hardcoded to come from hadoop.properties. We can easily fix this by using configuration properties. Just need to agree how generic config properties would be named and used:
```
<hdp:configuration properties-location="${xd.config.home}/hadoop.properties"/>
to
<hdp:configuration file-system-uri="${spring.yarn.fsUri:hdfs://localhost:8020}"/>
```