Merge Telemetry TCK into a single archive

[jasondlee]

Move sources and resources
Update POM file
Modify artifactID to match
Merge READMEs

Resolves #244

[brunobat]

This PR reduces the wiring triplication on the TCK.
We can run independent tests for tracing, metrics and logging by tweaking the test config file. A point in favor of keeping things separated but that can nevertheless be achieved with this PR.

[jasondlee]

Right. This doesn't prevent someone from running tests for just one signal type (I'm not sure why one would, as that's not how TCKs work, think :) , but it does make it easier to set up the environment to run the suite in general.

[Emily-Jiang]

I think having separate archives allows the runtime to just focus on one set of tcks if they only support subset of this spec. Besides, the three pillars have different progress on making changes etc.

[jasondlee]

My guess is that the general case is that someone is implementing "the spec" and we should optimize for that. Someone can still test only one pillar if so desired. The process would be same (configure with a single jar), but the tests would be restricted to a given package. Playing the "what if" game too much (e.g., "what if someone only wants to support JVM metrics and not application?") can lead (as is the case here, I think) of optimizing for random, probably rare (ish) scenarios, which increases complexity for more common cases with little added value.

I'm not sure the pace of development per pillar is relevant here, as the MP Telemetry spec pins otel to a given version, and the TCK covering all three pillars (whether in 1 jar or 3) is released with a single version (that of the spec) covering that version of otel. We are not producing pillar-specific TCK artifacts with varying versions, so this seems moot.

[Emily-Jiang]

I don't feel there is a business need for merging the archives. I prefer to keep as it is for now unless there are business reasons arsing for the merge.

[jasondlee]

I don't see a business NOT to merge it, as it both maintains current flexibility while lowering the barrier to entry by reducing complexity. The only "valid" argument I can see is maintaining the status quo, but I find that pretty uncompelling.