Rethink function interfaces

[redeboer]

As discussed with @jonas-eschle in #521, seems be evolving to a package that streamlines the creation of back-end agnostic, array-oriented functions from large (SymPy) expressions with many parameters.

The most general function interface, Function, seems fine for this purpose. We have to think more carefully what are the responsibilities of classes that implement this interface. (Should the interface for instance also expose which backend it is using?)

The ParametrizedFunction interface is more problematic. It has a update_parameters() method, as it came from the original intend of making this a fitting framework (see ComPWA-legacy). However, this method makes that function interface stateful and this makes it hard to multithreading, JIT-compilation, autodiff etc.

Some other ideas that came by:

• Perhaps the classes in the tensorwaves.interface module should be Protocols instead of abstract base classes to facilitate interoperability (you don't want to have to derive them, or be tempted to do instance checks). Think of UHI, for example.