Sketch for request/reply/alternate

This is mostly like what I've mentioned before, but it puts the reply 
endpoint on the wire as <wsa:ReplyTo> and likewise for [fault endpoint].

    * Instead of [reply endpoint] and [fault endpoint] MAPs, we have an
      [endpoints] MAP (or whatever we want to call it).  This is a set
      of /(qname, /EPR) pairs (not (IRI, qname)).  We pre-define
      wsa:ReplyTo and wsa:FaultTo, which we tie to the usual semantics.
    * Instead of ReplyEndpoint and FaultEndpoint properties in the SOAP
      1.2 module, we have an Endpoints (or whatever) property with the
      same value as the [endpoints] MAP.  I believe the same approach
      used to back-port the current 1.2 module to SOAP 1.1 will work
      here, mutatis mutandis.
    * The Endpoints SOAP property is mapped to one header per pair,
      using the qname element of the pair as the header name.  So the
      wsa:ReplyTo entry becomes the wsa:ReplyTo header, the wsa:FaultTo
      entry becomes the wsa:FaultTo header, and the alt:AlternateReplyTo
      entry becomes the alt:AlternateReplyTo header.
    * Headers other than the pre-defined wsa:ReplyTo and wsa:FaultTo
      carry an attribute identifying them as endpoints.  This allows the
      receiver (and intermediaries) to reconstitute the
      [endpoints]/Endpoints properties without any special knowledge.