Redesign API to replace ad-hoc type hints in param names with actual type hints

[phargogh]

We have a variety of parameters throughout pygeoprocessing where the parameter name includes the type of the parameter. Examples include:

• base_raster_path_band_const_list in raster_calculator
• base_raster_path_listin align_and_resize_raster_stack
• resample_method_list in align_and_resize_raster_stack
• raster_driver_creation_tuple in a number of functions

I don't remember why, exactly, we choose to denote type this way and not to use type hints, but type hints these days are pretty well-supported and a descriptive way for us to render the input types in places like the API docs.

If we do this, we should be careful about the update, since this will change a large number of parameter names throughout the package and break everything that calls it in the process.

So the proposal here is to do a major API change sometime in the future (pygeoprocessing 3.0 or 4.0) so that

• resample_method_list becomes resample_methods
• base_raster_path_band_const_list becomes something simpler, maybe inputs?

A trimmed down version of this that wouldn't break compatibility would simply be to add type hints everywhere, which itself would be a nice addition.

[phargogh]

We talked about this on the team call this morning and agreed that while a design doc is not necessary, it would be helpful to have a shared doc to review the changes and discuss. Many parameter names that could benefit from the change are shared across functions, so this would be a consolidated list.

We also talked about how this would make sense to go in a major pygeoprocessing release, perhaps along with a few other things like supporting URLs and formally handling the forthcoming GDAL 4.0 change where exceptions are enabled by default. Changes like these may end up on a roadmap of some kind through github projects.