- complete signature to be `run`
- fix test
- orangecontrib: make inheritance to `Registered` instead of `OWEwoksWidget`
Because `OWEwoksWidget` enforce to use the defined ewokstaskclass which is not something we want for now (avoid task associated with gui, processes on threads...)

For now process is always call. When call from workflow_concept it insure the input has benn provided previously. Otherwise you should provide the xas_object. It might evolve with time.

Add some simple unit test to insure an orangecontrib est workflow can be converted to a graph and a graph to an est workflow.
Add test to insure we can execute it as well

Make `Process` inherit from Task
Create a OWESRFWidget which inherit from OWWidget and implement stuff for the task graph.

OWESRFWidget fir the expected design for the esrf task graph. Creating a OWWidgetTaskExecutor for example

processing source code used:

input_ows_file = "..."
from esrf2orange3.owsconvert import ows_to_esrf, esrf_to_ows
from esrftaskgraph.graph import TaskGraph
graph = ows_to_esrf(input_ows_file)

[orangecontrib][larch] add a call to `_updateProcess` on larch widget initialization to insure `_larchSettings` is updated if there is no modification of the parameters

[orangecontrib][larch] normaize call to larch: from the main thread with some callback to QApplication.processEvents

[orangecontrib] add _ParameterWindowContainer to add a auto/manual option for computation in OW from larch and pymca

- orange signal 'spectra' is renamed xas_obj
- update to the new orange way to define Input and Output
- add a converter widget to convert from xas object to data table

[orangecontrib] update xasobject copies to duplicate the associated h5 file (storing processing flow)

[orangecontrib][larch] add a _USE_THREAD variable to skip processing on thread for larch orangewidget for debugging

[orangecontrib] rework the display for ft and kweight. kWeight is displaying nothing for the time beeing.

Everything is displayed by ft througt to 'spectrum' display: the window and the ftintensity

Now if a new request is required for processing and the processing thread is running, skip the request. Simplify thing.

[pool process + processing thread] proto - make processing in a pool and start from a separated thread to avoid gui freeze.

Move Normalization to multiprocessing.Pool and the call from orange from a dedicated thread and with a QThreadPool.
This prevent any gui freeze.
For now this is just a prototype. Some thing to do:

- create a pool_process that will be inherited from PyMca_normalization and QPyMca_normalization.
- generalize this structure for each orange widget.

- create core/progress module which contains `Progress` class used to give some feedback about the advancement
- create orangecontrib/progress module to overwrite Progress functions with a QSignal in order to connect this processing to the orange widget.
- this require to move all core processing to classes (ft, exafs...) to keep the 'Progress' or 'QProgress' object