Add selection mechanism in graph

The main feature of this MR is to introduce the Select operator, allowing conditionnal graph execution. The condition can be data dependent, yet the graph scheduling remains fully static!

As per Aidge's philosophy, sub-graph hierarchy is an optional feature, not a mandatory workaround, contrary to ONNX's If operator or PyTorch torch.cond method. The Select operator has the following advantages over them:

• Allow interleaved and hierarchical conditions;
• Allow pre-execution of conditional branches or not.

Two scheduling behaviors are possible, depending on wether Scheduler::tagConditionalNodes() was called or not:

1. Without tag: the graph is scheduled and run as is, meaning every conditional branch is run before selection. Of course, this may lead to lots of unnecessary computation. However, branches can be run in parallel, as well as in parallel with the condition determination path;
2. With tags: only the selected conditional branch is run. To achieve this, the condition determination path has to be scheduled and run entirely before any conditional branch.

This MR adds the following:

• Operator Mod (modulus), conformant to ONNX;
• Operator CryptoHash, for computing SHA256 (using OpenSSL, now an optional dependency to aidge_backend_cpu);
• Operator Select, which selects one of its inputs;
• The Scheduler::tagConditionalNodes() method that tags nodes with their conditions in the schedule.cond attribute;
• Adaptation of the Scheduler to take into account the schedule.cond nodes tag;
• Addition of analysis/ sub-folder with the StaticAnalysis and OperatorStats now in separate source files;
• Addition of DynamicAnalysis class that has the same functions as StaticAnalysis but on the scheduled graph. The DynamicAnalysis will therefore report stats for the actual graph execution, which may differ from the static graph if for example some nodes are run multiple time (in recurrent/cyclic graphs) or never run (conditional node);
• Add unit tests for GraphView::replace() from !281 (closed);
• Registrar now also displays the list of available keys when a key is not found;
• Solves #240 (closed).

Example

In the following example, we implement a conditional graph where the condition depends on the input data.

%%{init: {'flowchart': { 'curve': 'monotoneY'}, 'fontFamily': 'Verdana' } }%%
flowchart TB

Producer_0("input<br/><sub><em>(Producer#0)</em></sub>"):::producerCls_rootCls
CryptoHash_0("hash<br/><sub><em>(CryptoHash#0)</em></sub>")
Mod_0("mod<br/><sub><em>(Mod#0)</em></sub>")
ReLU_0("relu fa:fa-circle-question<br/><sub><em>(ReLU#0)</em></sub>")
Tanh_0("tanh fa:fa-circle-question<br/><sub><em>(Tanh#0)</em></sub>"):::conditionCls
Sqrt_0("sqrt fa:fa-circle-question<br/><sub><em>(Sqrt#0)</em></sub>"):::conditionCls
Select_0("select<br/><sub><em>(Select#0)</em></sub>")
Producer_1(<em>Producer#1</em>):::producerCls
Producer_0-->|"0 [2, 3] Float32<br/>&darr;<br/>0"|CryptoHash_0
Producer_0-->|"0 [2, 3] Float32<br/>&darr;<br/>0"|ReLU_0
Producer_0-->|"0 [2, 3] Float32<br/>&darr;<br/>0"|Tanh_0
Producer_0-->|"0 [2, 3] Float32<br/>&darr;<br/>0"|Sqrt_0
CryptoHash_0-->|"0 [4] UInt64<br/>&darr;<br/>0"|Mod_0
Mod_0-->|"0 [4] UInt64<br/>&darr;<br/>0"|Select_0
ReLU_0-->|"0 [2, 3] Float32<br/>&darr;<br/>1"|Select_0
Tanh_0-->|"0 [2, 3] Float32<br/>&darr;<br/>2"|Select_0
Sqrt_0-->|"0 [2, 3] Float32<br/>&darr;<br/>3"|Select_0
Producer_1-->|"0 [1] UInt64<br/>&darr;<br/>1"|Mod_0
Select_0--->|"0 [2, 3] Float32<br/>&darr;"|output0((out#0)):::outputCls
classDef inputCls fill:#afa
classDef outputCls fill:#ffa
classDef externalCls fill:#ccc
classDef producerCls fill:#ccf
classDef genericCls fill:#f9f9ff,stroke-width:1px,stroke-dasharray: 5 5
classDef metaCls stroke-width:5px
classDef rootCls stroke:#f00
classDef producerCls_rootCls stroke:#f00,fill:#ccf
classDef genericCls_rootCls stroke:#f00,fill:#f9f9ff,stroke-width:1px,stroke-dasharray: 5 5
classDef metaCls_rootCls stroke:#f00,stroke-width:5px

TODO later

• Add support of conditions in node exports;