Proposal for Async Extensions

Attached please find a proposal for extensions for handling asynchronous
behavior.  This was an action item of mine from last Wednesday's call.

I believe the attached proposal has several advantages over previous
proposals, namely:

    * No new SOAP MEPs are needed to handle asynchronous messaging over
      two-way transports.
    * Given that messaging over a one-way transport simply means sending
      a message, which any binding must be able to do, there may be no
      need for a "one-way SOAP MEP" at all.
    * Little if any change is needed to the existing HTTP SOAP binding.
    * Acknowledgments may be explicitly correlated via [message id] and
      may carry any other needed information.
    * There are precise and complete rules for what combinations of
      addressing headers are allowed in what circumstances.
    * The [response binding] element covers the "Multiple Connection
      HTTP" use case as a special case.
    * Other bindings with backchannels are straightforward.
    * It includes Tony's Timeline explicitly, addressing concerns about
      when faults may or must be sent on the backchannel.  We may want
      to tone down some of the statements made in this section, but this
      can be done without disturbing the rest of the rules.
    * It's short.  Most of the bulk is illustrative examples.  The
      normative material runs to a page or two.