Add workflows and exchange exposition.

[dlongley]

This PR adds some much needed exposition on workflows and exchanges.

---

Preview | Diff

[TallTed]

This is a partial rewording. More is needed, especially on the verifiablePresentation case. It's not clear to me what is meant, so I cannot rephrase that sentence. The troublesome bit is such as issued verifiable credentials or verifiable credentials provided in response to the exchange client's request where it's not clear to me what the alternatives are. Maybe such as previously issued verifiable credentials or newly issued verifiable credentials provided in response to the exchange client's request would work here? (It would likely help if things were marked up with [=these=] and related wrappers. Why aren't those liberally sprinkled over this text?)

Suggested change

	If that object is empty, the exchange is complete and nothing is requested nor
	offered to the exchange client. If the object includes
	`verifiablePresentationRequest`, then the exchange is not yet complete and
	some additional information is requested, based on the contents of the
	associated verifiable presentation request. If the object includes
	`verifiablePresentation`, then some information is offered, such as issued
	verifiable credentials or verifiable credentials provided in response to the
	exchange client's request. If the object includes `redirectUrl`, the exchange
	is complete and the workflow service recommends that the client proceed to
	another place to continue the interaction in another form.
	If that response object is empty, the exchange is complete and nothing is
	requested from nor offered to the exchange client. If the object includes
	`verifiablePresentationRequest`, then the exchange is not yet complete and
	some additional information is requested, as specified by the contents of the
	associated verifiable presentation request. If the object includes
	`verifiablePresentation`, then some information is offered, such as issued
	verifiable credentials or verifiable credentials provided in response to the
	exchange client's request. If the object includes `redirectUrl`, the exchange
	is complete and the workflow service recommends that the client proceed to
	another place to continue the interaction in another form.

[dlongley]

Adding suggestion and will come back to this to resolve the rest of the comment.

[dlongley]

Ok, I've tried to clarify this with the latest changes. In short, a VP could include VCs that were issued to the holder that is operating the exchange client OR the VCs could be about whomever is operating the exchange server, i.e., if the holder used their exchange client client to ask a website to provide its own credentials before the holder is willing to continue in the exchange.

[dlongley]

Regarding [=foo=] ... that pattern doesn't exist at all in the spec at this time (AFAICT). A subsequent PR that adds that sort of thing will need to be done over the whole document, I expect.

[dlongley]

Thanks @TallTed! I've applied most of your changes, responded to three (I think it was 3) of your suggestions, and asked for a re-review.

[TallTed]

Suggested change

	depends on the workflow service implementation, the complexity of the workflow
	the exchange is based on, and the options provided by the coordinator when
	the exchange is based on, and the options provided by the coordinator when

[dlongley]

This got a little weird so I applied a separate fix for it.

[dlongley]

@TallTed, everything look good to you now?

[TallTed]

This change (delete s) is needed for agreement with the other tweaks by me, @dlongley, and @msporny.

Suggested change

	VC API exchange protocols. The protocols supported depends on the complexity
	VC API exchange protocols. The protocols supported depend on the complexity

[msporny]

:( -- your change went in 9 minutes after the PR was merged... can you do this in a new PR (with whatever else you might find)?