`pvlib.iotools.get_pvgis_hourly`'s `surface_azimuth` parameter doesn't use pvlib's azimuth convention

[kandersolar]

Nearly everything in pvlib represents azimuth angles as values in [0, 360) clockwise from north, except pvlib.iotools.get_pvgis_hourly:

pvlib-python/pvlib/iotools/pvgis.py

Lines 79 to 81 in 3def7e3

	surface_azimuth: float, default: 0
	Orientation (azimuth angle) of the (fixed) plane. 0=south, 90=west,
	-90: east. Ignored for tracking systems.

This inconsistency is a shame. However, I don't see any way to switch it to pvlib's convention without a hard break, which is also a shame. I wonder how others view the cost/benefit analysis here.

See also #1395 (comment)

[cwhanse]

Since get_pvgis_hourly is only using surface_azimuth to pass a value to a pvgis keyword aspect, we could add aspect with the South=0 convention and deprecate surface_azimuth as is. Then later, we can deprecate aspect and add surface_azimuth back with its pvlib meaning. Now that I write that out, seems better just to make the breaking change.

[tongpu]

This issue discusses that surface_azimuth in get_pvgis_hourly should be changed to clockwise from north, but the documentation in pvgis.py mentions counter-clockwise from north, even though the implementation 'aspect': surface_azimuth-180 matches what was discussed in this issue.
I would have a PR at the ready if this is not a misunderstanding on my side.