Add a multistep workflow example with branching steps generated from step templates

[dlongley]

It would be good to show an example with multiple branching steps that are determined by results from previous steps and computed from step templates.

One such example could be a workflow that accepts a VPR from the client in the first step and responds with VCs in the either the next step or a subsequent one, where intermediate steps do not generate any output to send to the client, but just store results for the step templates to use.

So one idea:

First step: Allows an exchange client to (optionally) send its own VPR (optionally validated against a schema as well).

Second step: Uses the stored VPR (from exchange.variables.results[firstStep]) in its step template to either: send either a stored VP with VCs or issue VCs into results. The next step (none or third step) is determined by this choice.

Third step: Include the issued VCs from step 2 in a VP, along with other VCs that are issued in this step.

[msporny]

The example should probably go here: https://w3c-ccg.github.io/vcalm/#workflow-step-and-template-examples

[msporny]

An example needs to be created in this issue before we can move it into a PR.

[dlongley]

We might want an example that demonstrates that partial results could be computed while processing a particular step, i.e., a particular step template might self-reference results for itself when looping through exchange processing or if there are multiple entry points into processing an exchange (based on the protocol in use).

This is useful for at least two use cases:

1. Steps that might reconfigure/generate different issueRequests based on whether a VPR is provided by the client: the first time the step is processed the client's VPR is stored and then the step is considered incomplete, allowing it to be reprocessed with the added information (in the next iteration of a processing loop).
2. Steps that might require additional information to proceed based on protocol requirements, i.e., OID4VCI 1.1 has a mode that requires "interactive authorization" to occur using one endpoint -- that would receive inputs to be stored in the results for a step -- and then another endpoint would actually try to complete the step by issuing the VCs from the issueRequests that were regenerated on the basis of this information.

A single workflow can be created that supports both of these protocol approaches at once.