Bug 2437

This should be fixed but needs to be tested.

Taking ownership of all of slang's WSC bugs.

There seem to be at least two different problems handling these sorts of
messages.

For example, when talking to a java service container and providing an invalid
service path, the container response with a soap message containing no headers
at all, just a fault in the body. Checking the spec, it looks like the header
block is optional, so the client bindings code should probably be a bit more
careful. It's probably worthwhile to invok the response trigger if there's no
header, but if it fails (missing addressing headers or whatever) ignore that
unless the body doesn't contain a fault.

When doing the same thing to the c container, the response is constructed with
some of the ws addressing headers, but the wsa:RelatesTo header contains no
content. This confuses the ws-addressing handler.

I committed some fixes to the service side in the c code. The check for message
id in the response handler was checking the wrong value for nullness, and thus
not generating an error. Fixing that triggered a recursive fault generation
problem in the messaging API which is also fixed, so clients talking to the
services can figure out the proper error now.

The java behavior of omitting the soap:header element will require more changes
to the bindings generator to get things handled more nicely.

Committed a fix to the java case (fault without any headers) this in the trunk.
The java code reported doesn't actually generate this type of error any more in
the gt4.0 branch.

While fixing this bug, I restructured the client stubs a bit in the trunk so
that  the client state machine is now in the soap messaging library instead of
in the bindings implementation of each operation. This change will make fixing
state machine bugs much simpler (direct code to change, one package to update),
and will also make features like intra-container invocation of services much
easier to implement.

joe