ADR Suggestion New easyscience API structure, the Job structure.

[damskii9992]

General

The Job API structure was first suggested in the context of EasyDiffraction (see easyscience/EasyDiffractionLib#96) as a means of providing a structured and reasonable API for the user. The API is how the user uses our software and it should be as simple as possible while being logical and easy to use.
The Job API structure is meant to be used across the technique-dependent libraries, and I here propose to use the same structure for the easyscience library.

Current implementation

Currently, the easyscience API mimics lmfit and is used as:

from easyscience.fitting import Fitter
from easyscience.Objects.ObjectClasses import BaseObj
from easyscience.Objects.new_variable import Parameter

a = Parameter(name='a', value=-1)
b = Parameter(name='b', value=7)
c = Parameter(name='c', value=3)

quad = BaseObj(name='quad', a=a, b=b, c=c)
fitter = Fitter(quad, math_model)
result = fitter.fit(x=x, y=y, weights=1/yerr)

Here, 'quad' is a BaseObj, i.e. a container of the fitting Parameters a, b, and c, similarly to the Parameters class from lmfit which also contains the parameters and passes them to the minimizer.
The math_model is a function or other callable which uses the parameters and x-values to predict the y-values:

def math_model(x):
    return a.value * x ** 2 + b.value * x + c.value

This could also have been a class object with an implemented __call__ dunder method. This differs slightly from lmfit where the model has to have the parameters as input (rather than reference them globally as in easyscience).

In the more complicated technique-dependent libraries, the math_model is replaced with the external calculator (or rather, our wrapper around it), and the 'quad' BaseObj is replaced with a hierarchy of BaseObjs which describes the theoretical system.