[FEAT] CasePathResolver: Allow to infer pending elements

[tbouffard]

DISCLAIMER: this issue describes path computation for a single instance/case only. So the implementation will go to the CasePathResolver class as it differs from PathResolver which is a generic implementation that both deals with single instance or all instances of a process.

Is your feature request related to a problem? Please describe.

In #16, we allow to pass pending elements in the input of the path computation but we are not inferring any pending elements that follow completed elements.

Describe the solution you'd like

First compute the path with provided completed and pending elements (#16).

Then infer direct (i.e. following the latest completed element in the graph) pending elements when enabled with an option see #23.
This includes

• the following flownode/shape considered as pending.
• the following flow/edge considered as completed (the flow between the latest completed and the inferred pending element). They are in the "outgoing "array of the "latest" element.

Questions

Note: depending on the answers, the question can lead to the creation of a new issue.

• How do we find the "latest" elements? in particular, there may be several terminal elements!

• If there are several pending candidates for pending elements, for instance the latest element is an exclusive gateway, how do we handle it (see [FEAT] CasePathResolver: categorize the elements returned in the inferred path #24)

• How do we handle "hole" in the graph? In this case, a basic implementation would return false results

• Completed gateways as "latest" element of the path

  • parallel: all outgoing flows are considered as computed
  • other: none can be considered as part of the path. They can only be considered as candidate, see [FEAT] CasePathResolver: categorize the elements returned in the inferred path #24
  • see also [FEAT] CasePathResolver: handle "forward lonely edge" from an exclusive gateway targeting a merge exclusive gateway #10 and [FEAT] CasePathResolver: handle "backward lonely edge" with exclusive gateways #14

### Tasks
- [ ] README: explain that the algorithm doesn't cover all tricky use cases and inconsistency
- [ ] README: You are supposed to pass valid inputs as they come from your system There is no plan to detect such inconsistency that must be done in the caller code