- rename `process` to `run` and
- replace output.var_namevar.value by outputs.var_name and input.var_namevar.value by inputs.var_name
- _INPUT_NAMES and _OUTPUT_NAMES where missing (larch processes...)

update value from list to set

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.

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)

In fact instead of having to repeat those definitions n times we should have some king of a database defining those once for all

- add `outputs` and `inputs` entries in processing classes used in ppfaddon aliases file.
- add `get_xas_obj` function in est.app.utils module
- mode est.app.utils._convert_spectra_dims to public

- refactor types to create submodule
- Spectra is now a class instead of a simple list from XasObject
- Spectra contains data which is a numpy ndarray of Spectrum. This was it is simpler
to reshape it andd should offer some flexibility for the futures.
- this is the main PR but several smaller one are expected to come for cleaning...

There was a bug when saving ft.radius... that can be nan or numpy array. When try to save it as a numpy array then it ends up as an array of dtype 'object'.
So to fix it we now store this as a dictionnary.
And we add a try-except section when saving keys if return in the future is unsafe for hdf5.

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

fix 6f127e5e, process, progress.. should still be part of xas.process

- now process can take an output and an output_dict for storing the result in a multiprocessing.Proxy object
- rework process action to avoid several call to pymca `processSpectrum` function
- add an option to XasObject `to_dict` function to simply store raw data (which is the reference), but also to keep processing results to be used later.
This is need for the 'non gui' workflow processing which uses a dictionnary instead of a XasObject.

[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

- simplify the bases structure Spectrum and XASObject to be more generic and continue workfing with pymca.

- simplify the bases structure Spectrum and XASObject to be more generic and continue workfing with pymca.

- create callable classes in order to get the setParameters function.
- copy parameters to the xas_obj processed.
- /close #2

[io] rework spectrum, to separate exafs and FT. Should even be other variable. Update the output configuration