TCK: spi/soap tests

I'm not sure if all of this is a challenge or if I just don't understand how the ported `spi/soap` tests in the 3.1.x TCK are supposed to work.

First, for purposes of EE 11 implementations, shouldn't these tests be optional? The test application requires SOAP/XML WS which were [removed as technologies](https://jakarta.ee/specifications/platform/11/jakarta-platform-spec-11.0-m4#a2333) from the platform in EE 11. As such, we'd want a property to control their execution in the TCK, similar to the `skipJACC` one that's already available for those tests.

Second, is it understood that a user is supposed to make some pom-level changes in order to make these work? There's nothing in particular in the TCK guide about these tests. I'm attempting to execute them against Open Liberty and they blow up on the test side with this exception:

```
java.util.ServiceConfigurationError: com.sun.xml.ws.assembler.metro.dev.ClientPipelineHook: Provider com.sun.enterprise.security.webservices.client.ClientSecurityPipeCreator not found
at java.base/java.util.ServiceLoader.fail(ServiceLoader.java:601)
at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.nextProviderClass(ServiceLoader.java:1233)
at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextService(ServiceLoader.java:1242)
at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext(ServiceLoader.java:1292)
at java.base/java.util.ServiceLoader$2.hasNext(ServiceLoader.java:1328)
at java.base/java.util.ServiceLoader$3.hasNext(ServiceLoader.java:1412)
at com.sun.xml.ws.util.ServiceFinder$CompositeIterator.hasNext(ServiceFinder.java:282)
at com.sun.xml.ws.util.ServiceFinder.toArray(ServiceFinder.java:227)
at com.sun.xml.wss.provider.wsit.SecurityTubeFactory.loadSPs(SecurityTubeFactory.java:363)
at com.sun.xml.wss.provider.wsit.SecurityTubeFactory.getClientTublineHooks(SecurityTubeFactory.java:280)
at com.sun.xml.wss.provider.wsit.SecurityTubeFactory.createTube(SecurityTubeFactory.java:217)
at com.sun.xml.ws.assembler.TubeCreator.createTube(TubeCreator.java:53)
at com.sun.xml.ws.assembler.MetroTubelineAssembler.createClient(MetroTubelineAssembler.java:112)
at com.sun.xml.ws.client.Stub.createPipeline(Stub.java:312)
at com.sun.xml.ws.client.Stub.(Stub.java:279)
at com.sun.xml.ws.client.Stub.(Stub.java:212)
at com.sun.xml.ws.client.Stub.(Stub.java:227)
at com.sun.xml.ws.client.sei.SEIStub.(SEIStub.java:68)
at com.sun.xml.ws.client.WSServiceDelegate.getStubHandler(WSServiceDelegate.java:806)
at com.sun.xml.ws.client.WSServiceDelegate.createEndpointIFBaseProxy(WSServiceDelegate.java:795)
at com.sun.xml.ws.client.WSServiceDelegate.getPort(WSServiceDelegate.java:426)
at com.sun.xml.ws.client.WSServiceDelegate.getPort(WSServiceDelegate.java:392)
at com.sun.xml.ws.client.WSServiceDelegate.getPort(WSServiceDelegate.java:373)
at jakarta.xml.ws.Service.getPort(Service.java:139)
at ee.jakarta.tck.authentication.test.basic.soap.HelloService.getHelloPort(HelloService.java:72)
at ee.jakarta.tck.authentication.test.basic.SoapProfileSPITest.runOnce(SoapProfileSPITest.java:80)
...
```

The `com.sun.xml.wss.provider.wsit` stuff in that stack comes from the glassfish dependency defined in the pom and doesn't have anything to do with Open Liberty. Before porting, these tests would have been run through the JavaTest environment which allows an implementation to define the classpath, etc. in `ts.jte` for test execution.

Start with the ported 3.1.x TCK spi/soap tests, the existing skipJACC property, and the test application's pom. Read the TCK guide and compare the prior JavaTest ts.jte execution setup. Done should clarify the expected pom/classpath configuration and provide a way to control SOAP test execution for EE 11 implementations.

Written by the indexing model from the issue text.