ENH: Rationalize get_band_path functions

[remi-braun]

It could be great to rationalize all the functions that gravite around get_band_path, and see which one needs to be public or private.
The actual issue is that this function orthorectifies, reprojects in UTM or geocodes the arrays under the hood, which can be time consuming and not desired.

So it could be better to disambiguate these function names:

• get_band_path: Main function that orthorectifies, reprojects in UTM or geocodes the arrays under the hood.
• get_existing_band_paths: Get all the paths for all the existing bands and relies on get_band_path
• get_default_band_path: Get the path of the default band and relies on get_band_path
• _get_raw_band_paths: Get the raw band file path, SAR only. This may need to be made public and generalized to optical data ?

Other sensor specific function that may need to be grouped or generalized:

• _get_preprocessed_band_path: Get the path of preprocessed Sentinel-3 data
• _get_utm_band_path: Get the reproject/orthorectified the VHR bands to UTM

Other functions managing paths but which don't pose any problem:

• _get_clean_band_path: Get the path for cleaned data, optical only.
• _get_cloud_band_path: Get the path for cloud data written on disk, optical only.

If no clearer way of managing this is found, at least an update in the documentation is needed.

[remi-braun]

Manage raw band files in a better way, for example using a regex and factorizing the code.

[remi-braun]

get_raw_band_paths becomes public and is generalized to all products.

[remi-braun]

get_raw_band_paths becomes public and is generalized to all products.

This must be documented (i.e. in VHR/SAR notebooks)

[remi-braun]

💡 It would also be nice to be able to retrieve all the band paths (spectral bands, but also DEM, clouds and spectral indices) with get_band_paths
➡️ One big question though for get_band_paths alignement: should it compute the paths asked (copied on non-ortho bands)
🔗 From #80