This PR specifies the tolerance argument only for certain versions of Rasterio and above (to avoid undefined keyword arguments being passed to GDAL), and re-structures chunked operations to be more logically organized (and avoid circular import conflicts).

Tolerance argument

I realized we forgot to add this @vschaffn:

  if Version(rio.__version__) > Version("1.4.3"):
        reproj_kwargs.update({"tolerance": 0})

Organization of chunked operation

Additionally, this PR re-writes _reproject() to call on a single and consistent _rio_reproject() function either directly or through _reproject_block() within Multiprocessing or Dask (otherwise we had 2 different codes running reprojection).
This allows to have consistent behaviour (output dtype, nodata, number of threads and memory limit, etc).
And it will be useful to add Dask support in #446.

In terms of structure, this PR adds a _geotransformations.py module where all subfunctions of geotransformations that need to be re-used in other modules can be moved (e.g., for Dask/Multiprocessing chunked implementations of these functions).
It also moves out generic chunked functions from delayed_dask.py into a chunked.py module, where they are called from both multiproc.py (for Multiprocessing) and dask.py (renamed from delayed_dask.py, for Dask).

Original problem

The only problem was the code structure: Having _rio_reproject in raster/geotransformations causes a circular import problem, as it needs to be imported by _reproject_block in raster/distributed_computing/, which is contained in _reproject_multiproc (or _dask) there, that is finally imported in raster/geotransformations again.

So I've left _rio_reproject in raster/distributed_computing/ for now, but we might have to think about how this will affect our architecture, as there will be the exact same problem for every chunked operation we implement!