Consider synchronizing integration approach with other projects in zipkin

[codefromthecrypt]

Most zipkin integrations do not require a custom build, rather custom assembly. For example, zipkin-aws and zipkin-azure layer autoconfiguration on top of the base server. This allows people to mix and match things, for example using a kafka collector, but a google cloud storage. Importantly, this allows people to compose servers in their tool of choice, albeit docker, puppet, chef or doit.sh without a custom build.

One example of composition is amazon SQS here:

https://github.com/openzipkin/zipkin-aws/tree/master/autoconfigure/collector-sqs#running

You can see that this allows you to decorate properties on top of the builtin ones from Zipkin.

There's only one catch to this, which is that the maven setting (module) used there has been removed in spring boot 1.5 (openzipkin/zipkin-aws#32). Across all projects we would need a similar remedy to that.

See #33 for a discussion about restructuring. Restructuring is good, but I think it would be better to restructure similarly to other zipkin integrations such that support is easier.

[codefromthecrypt]

I opened a similar issue in spring-cloud-sleuth which is the other source of custom builds spring-cloud/spring-cloud-sleuth#555

[codefromthecrypt]

related to integrations.. our other clouds have a "sender" which might be appropriate here. This would allow apps who already use zipkin-reporter-java implicitly (like spring-cloud-sleuth, brave, wingtips, jaeger) to plug directly into stackdriver if they want. Those using spring would not need a custom server, unless they need to intermediate. See #37 for a longer chat on multi-cloud