Simplify the ImageCollection class hierarchy #100

We currently have a class hierarchy across openeo-python-client and openeo-geopyspark-driver:

• base class ImageCollection in openeo-python-client with child classes
  • ImageCollectionClient in openeo-python-client
  • GeotrellisTimeSeriesImageCollection in openeo-geopyspark-driver
  • GeotrellisCatalogImageCollection in openeo-geopyspark-driver, but deprecated and unused as far as I know

This hierarchy and relationship makes sense as these classes represent the same entity (data cubes), but from different view points: client side and backend-side.

However, these client and backend contexts are also quite different and the sharing of an abstract interface shouldn't be taken too far IMHO. Some examples and notes:

• the download method makes sense for the client, but is not very intuitive as verb at the backend side. Also the kind of arguments you expect to pass from client vs backend can be different.
• there is a lot of duplication of function arguments, type hinting, documentation, which is tedious to maintain. The have been already quite some changes to process definitions that resulted in somewhat ugly refactors in both projects (e.g. Confusing daterange and bbox filter methods on ImageCollection classes #67 )
• the client should work against all backends, while openeo-geopyspark-driver is very backend specific in practice (only VITO at the moment). This not ideal maintenance-wise. E.g. we might want to automate the availability of client methods for each officially defined process in some way (also see e.g. Client Guidelines vs ImagecollectionClient vs both #61, Dynamic Process function generation #40), for wide backend support, but this should be separate from the VITO backend.

I propose to simplify/reduce the shared API of the ImageCollectionClient base class a bit