Formulate exact requirements about stubbing Ladybug checkpoints, per checkpoint type

### Related Problem or Business Case

This issue is about clarifying the requirements of the Frank!Framework. The Frank!Framework makes use of Ladybug and thus cooperates with Ladybug to generate Ladybug checkpoints. Part of this is that Ladybug checkpoints can be stubbed. But the exact behavior of stubbing Ladybug checkpoints produced by the Frank!Framework is not clear. It may be different depending on the checkpoint type. Here are some questions / remarks:

* Stubbing a thread create, a thread start or a thread end checkpoint is meaningless, although the Ladybug GUI provides controls to do it. Shall we make a feature request to disable the controls to stub such checkpoints?
* Idem for info checkpoints.
* When you stub the end checkpoint of a sender, then the Frank!Framework does not execute the sender when the report is rerun. Is this a general rule that also applies to end checkpoints of pipelines and pipes (end checkpoints)?
* There are checkpoints that are leaf nodes, which means that they cannot be expanded. They do have a --> or a <-- arrow (input checkpoint or output checkpoint). I would expect the following. If a --> checkoint is stubbed, then the value in the report is substituted before the pipe / pipeline is executed. If a <-- checkpoint is stubbed, then the value in the report is substituted after the pipe / pipeline is executed and thus modifies the output after execution of the original element.
* If a start checkpoint is stubbed, does it mean that the value of the report replaces the original input of the pipe / pipeline before it is executed?

And do these cases correspond to real use cases? If not, we may disable stubbing for some more checkpoint types.

Consider this issue done when these questions are answered and when the answers have been expressed in issues for the Frank!Framework or Ladybug.

### Describe the Feature

See above.

### Collaboration with External Companies

No, community resolution only

### Anything else?

_No response_