Changes

Proposed Opentracing TCK Core Implementation
This PR proposes the core of the opentracing TCK implementation for
discussion. Highlights:
- Assumes that the application server under test provides a
[MockTracer](https://github.com/opentracing/opentracing-java/tree/master/opentracing-mock)
to the test application. Based on the opentracing spec, this is
`@Inject`ed into the `Tracer` in the JAXRS
`org.eclipse.microprofile.opentracing.tck.application.TestWebServices`
class. In addition to a "Hello World" JAXRS endpoint that will be
tested, this class has a method named `getTracer` which will be called
by the Arquillian client to return the information stored in the
`MockTracer` so that the client can assert the expected opentracing
spans. In addition, this class has a method named `clearTracer` which
can be called in between tests to clear the `MockTracer`.
- The method `TestWebServices.getTracer` uses reflection to access the
information of the `MockTracer`. The reason this is done instead of
bringing in the `io.opentracing:opentracing-mock` dependency directly
and casting the `Tracer` to `MockTracer` is that we don't want to assume
that the application's classloader has visibility into the classloader
that created the `Tracer` (if there is no such visibility, a
`ClassCastException` will occur).
- The method `TestWebServices.getTracer` converts the data in the
`MockTracer` into a `TestTracer` and `TestSpan`s which abstracts out the
logical information in the `MockTracer` (this is also needed because
`MockTracer` is not a POJO so its data is not transparently serialized
by `Jackson`).
- The class
`org.eclipse.microprofile.opentracing.tck.OpentracingClientTests` is the
`Arquillian` test class. In the `createDeployment` method, we generate
the WAR that gets installed into the target application server.
- There is a single test, `simpleTest` which has the `@RunAsClient`
annotation meaning it will run in the `Arquillian` test harness and act
as the JAXRS client. In `executeHelloWorld`, we get get the remote
`TestTracer` and call its `spanTree` method which returns a
`TestSpanTree`. This converts all of the spans into a tree data
structure which allows for easier comparison (to assert equality) and
also overrides `toString` to print out a JSON-like representation of the
tree of spans (if the equality assertion fails, it's nice to compare the
trees to see what's different).
- Finally we build a simulated `TestSpanTree` of the spans that we
expect the response to give, and we assert equality between the two. The
`TestSpanTree` and its tree of `TestSpan`s override `equals` to
recursively perform the comparison based on the number of spans at each
level and the spans' operation name and span kind attributes.
Signed-off-by: Kevin Grigorenko <kevin.grigorenko@us.ibm.com>

Add contributor to the NOTICE file

Add contributor to the NOTICE file

Update dependency versions to match already approved versions