Support use of arquillian REST protocol

[Azquelt]

• Ensure that requests from the arquillian framework itself are ignored by the InMemorySpanExporter
• Remove reference to the servlet API
• Avoid using "/" path in a test application
  • The arquillian rest protocol includes a rest resource class with @path("/"). Autodiscovery for the test application is also picking up the arquillian class. If the test application also has a resource method mapped to "/", the server will fail a request to that path.

Fixes #72

[Azquelt]

It's worth noting there are other ways to fix this problem.

We could start a test span at the start of each test without the parent context. When we query the InMemorySpanExporter, we could look only for spans with a traceId which matches the test span. However, this may make it harder to tell what has gone wrong if a test fails since the span is not found rather than found with the wrong traceId. It also makes it harder to ensure that the implementation is not accidentally making extra spans with a different traceId. In the OpenLiberty tests we get around this by logging if the InMemorySpanExporter exports a span which is not claimed by any test at app shutdown and then checking the logs, but we can't do that in the TCK.

The problem of having a test REST application pick up the Arquillian REST resource, causing a conflict if the test application has a resource mapped to "/" is very unfortunate. I'd like to see if there's anything we can do in Arquillian to avoid this happening.

We could work around it by implementing getClasses() to avoid triggering autodiscovery, but we'd need to do that consistently in every test application.

[Emily-Jiang]

LGTM