Package structure

[VeckoTheGecko]

As we move into version 4, I would like to see an update to the structure of the parcels package to something along the lines of:

parcels
├── __init__.py
├── _core
│   ├── __init__.py
│   ├── field.py
│   ├── fieldset.py
│   ├── grid.py
│   ├── interpolation_utils.py
│   ├── utils.py
│   └── ...
├── tutorial.py # or example.py, a namespace for us to put utilities like downloading datasets that are specific to the tutorial notebooks
├── _loggers.py
├── warnings.py
├── errors.py
├── _version.py
├── _repr.py
├── _compat.py
├── _typing.py
├── _datasets # namespace to put utilities for generating xarray datasets for use in testing or tutorials
│   ├── __init__.py
│   └── ...
└── ...

I propose implementing this final structure at the end of version 4 development so that we don't interfere with the development process with merge conflicts due to many renamed files and moved functions.

This structure has the following benefits:

• Improved organisation: Delineates which parts of the package are core to Parcels (grids, fields, particles, particlesets, writers, interpolation helpers), and which are more "stand alone" supporting code (user utilities, warnings, reprs, compatability items, dataset generation).
• Allows us to craft our namespaces: Currently our __init__.py files have many from ... import * statements meaning that sometimes things can creep into the public API on the parcels. namespace by accident just when added to a file. This also has the side-effect of running into circular imports. By promoting mostly empty __init__.py files, and by selectively importing in parcels/__init__.py we can be selective and have more control over what we expose to the user under the parcels. namespace.
  • Makes the codebase "private by default": With this new structure (namely having _core), items coming into the public API becomes a conscious decision.

[VeckoTheGecko]

I think this is actually quite important, since funkiness in the current structure combined with the wildcard imports are not only resulting in long (20s!) import times, but are resulting in a bit of clobbering of our public API in unpredictable ways affecting users (@jimena-medinarubio ) of our package.