[13pt] Remove Grass from solution

[RobHanna-NOAA]

Found in r_grow_distance.py and possibly some other places.

Recommended by Yan to be removed for performance reasons. It created perm issues in Windows and EC2's (but both got around it).

Possible alternatives: Whitebox (Jim found) or Numpy (Matt might have something on this).

Grass would need to be removed from the Dockerfile and whatever its replacement is will likely be added to the Pipfile. Could be needed in Dockerfile but Pipfile is best if possible)

[mluck]

Continuing from #702:
A comparison of GRASS vs. Whitebox resulted in nearly identical outputs. I confirmed that the projection issue seems to be a result of the inexact cell size value in the GRASS processes. For example, the agree_bufgrid_allo.tif from GRASS has a different origin than that of the original DEM data whereas Whitebox is the same as the DEM:

HUC8: 3100204	Origin(GRASS)	Origin(Whitebox)
dem_meters.tif	1335009.4094358840957284,610714.2824222166091204	1335009.4094358840957284,610714.2824222166091204
agree_bufgrid_allo.tif	1335009.4094358799047768,610714.2824222199851647	1335009.4094358840957284,610714.2824222166091204

As a result, there are slight differences in the REM rasters which originated from the stream lines being occasionally different using the two engines. In most cases this produces a random pixel shift here and there, but in a few cases the effect is more severe. In particular, the effect of slightly different stream lines accentuates other issues within the underlying datasets, most notably when it is located in conjunction with a thalweg notch.