Use declarative setup for SnapPy

[magnusuMET]

No description provided.

[heikoklein]

Looks generally good.

I don't see any necessity to move all scripts from the SnapPy folder to the SnapPy/snapscripts folder. This change will destroy the environments which run scripts directly without complete installation, which is often the case.

Moving snapAddToa from the bsnap debian package to snap-py debian package destroys the distinction between those two packages (bsnap: command-line tools, snap-py: graphical user interface (heavy qt requirements)).

Too many heavy changes for a pure cleanup.

[magnusuMET]

This does bring big changes, but helps reduce confusion in which package version one is running. It can be quite confusing when the import pulls in the installed package instead of the edited one. I find it more obvious to do this the pythonic way with pip install --editable. All places where scripts were being run directly has been changed to run from PATH afaik.

Is the distinction between bsnap and snap-py that obvious now? We have 8 programs under snap-py which does not depend on QT, in fact I have placed snapPy dependencies under extras. I think of bsnap as binary snap, a driver used by snapPy, and snapPy as all utilities supporting the model.

[heikoklein]

It is true that the scripts under utils/SnapPy consists for two reasons:
Graphical usage
"snapPy",
"snapCombineInverse", (invoked best from graphical, never used it non-graphical, but might be possible, maybe should be moved to bsnap?)

Operational usage:
"snap4rimsterm",
"snapNc2grib.py",
"snapRunnerNpps",
"snapRunnerNpp",
"eemepModelRunner",
"snapRemoteRunner.py",

So the operational ones could be removed from the debian snap-py package.

But not enough reason to put them all into another directory.

[heikoklein]

Rather than just moving to declarative setup.cfg, this PR requires many changes to the interna of the package. It hasn't been worked on in several month. And for a change to a declarative setup. PEP518/pyproject.toml (from 2016) should be used rather than setup.cfg. I suggest closing this PR and if still of interest, starting a new PR just replacing setup.py with pyproject.toml (for compatibility, please keep a boilerplate setup.py)

[magnusuMET]

The move to setup.cfg would greatly simplify conversion to pyproject.toml when python3.6 is phased out (pyproject.toml is not fully supported under 3.6)

[heikoklein]

This PR moves files, breaks in-place testing, changes filenames, breaks debian-packages and dependencies, without any benefit or reason except for transitioning to another build-system which we haven't even decided upon wanting to use. Please close silently.