Refactor processor method names for clarity and consistency

- Updated method names in the `BaseProcessor` class to follow a new naming convention based on input/output signatures:
  - `compute_11` → `compute_1_to_1`
  - `compute_n1` → `compute_n_to_1`
  - `compute_1n` → `compute_1_to_n`
  - `compute_n1n` → `compute_2_to_1`

- Adjusted related function calls in the `cdl_testdata.py`, `errorcatcher_unit_test.py`, `operation_modes_app_test.py`, and other test files to reflect the new method names.
- Updated documentation and changelog to reflect these changes and clarify the purpose of each method.
- Ensured backward compatibility is not maintained for these internal methods, targeting advanced developers and plugin authors.

Fix #180

Author: PierreRaybaut

CHANGELOG.md

@@ -2,6 +2,21 @@
 
 See DataLab [roadmap page](https://datalab-platform.com/en/contributing/roadmap.html) for future and past milestones.
 
+## DataLab Version 0.21.0 ##
+
+💥 New features and enhancements:
+
+* Generic processing types refactoring:
+  * Refactored the naming convention of core `BaseProcessor` methods implementing generic data processing patterns (e.g. one input ➝ one output, n inputs ➝ one output, etc.)
+  * New method names are now based on their input/output signature for better clarity and extensibility:
+    * `compute_1_to_1`: transforms each selected object independently
+    * `compute_1_to_0`: performs a measurement or analysis without generating a new object
+    * `compute_1_to_n`: generates multiple outputs from a single input (e.g. ROI extraction)
+    * `compute_n_to_1`: combines multiple inputs into a single output (e.g. sum, mean); supports pairwise mode
+    * `compute_2_to_1`: applies a binary operation between an object and a second operand (object or constant); supports pairwise mode
+  * These methods are internal and used by advanced developers (e.g. plugin authors); hence, **no backward compatibility is maintained**
+  * This closes [Issue #180](https://github.com/DataLab-Platform/DataLab/issues/180) - Rationalize `BaseProcessor` method names for core processing types
+
 ## DataLab Version 0.20.0 ##
 
 💥 New features and enhancements:

cdl/computation/base.py

@@ -174,11 +174,11 @@ class ConstantParam(gds.DataSet):
 # MARK: Helper functions for creating result objects -----------------------------------
 
 
-def dst_11(
+def dst_1_to_1(
     src: SignalObj | ImageObj, name: str, suffix: str | None = None
 ) -> SignalObj | ImageObj:
     """Create a result object, as returned by the callback function of the
-    :func:`cdl.core.gui.processor.base.BaseProcessor.compute_11` method
+    :func:`cdl.core.gui.processor.base.BaseProcessor.compute_1_to_1` method
 
     Args:
         src: source signal or image object
@@ -212,7 +212,7 @@ def dst_n1n(
     suffix: str | None = None,
 ) -> SignalObj | ImageObj:
     """Create a result  object, as returned by the callback function of the
-    :func:`cdl.core.gui.processor.base.BaseProcessor.compute_n1n` method
+    :func:`cdl.core.gui.processor.base.BaseProcessor.compute_2_to_1` method
 
     Args:
         src1: input signal or image object
@@ -241,9 +241,9 @@ def new_signal_result(
     units: tuple[str, str] | None = None,
     labels: tuple[str, str] | None = None,
 ) -> SignalObj:
-    """Create new signal object as a result of a compute_11 function
+    """Create new signal object as a result of a `compute_1_to_1` function
 
-    As opposed to the `dst_11` functions, this function creates a new signal object
+    As opposed to the `dst_1_to_1` functions, this function creates a new signal object
     without copying the original object metadata, except for the "source" entry.
 
     Args: