Remove pvgis_tmy outputformat='basic'

[AdamRJensen]

• I am familiar with the contributing guidelines
• Tests added
• Updates entries in docs/sphinx/source/reference for API changes.
• Adds description and name entries in the appropriate "what's new" file in docs/sphinx/source/whatsnew for all changes. Includes link to the GitHub Issue with :issue:`num` or this Pull Request with :pull:`num`. Includes contributor name and/or GitHub username (link with :ghuser:`user`).
• New code is fully documented. Includes numpydoc compliant docstrings, examples, and comments where necessary.
• Pull request is nearly complete and ready for detailed review.
• Maintainer: Appropriate GitHub Labels (including remote-data) and Milestone are assigned to the Pull Request and linked Issue.

PVGIS offers multiple output formats. For hourly data the file formats ['csv', 'json', 'basic'] are available, whereas for TMY data file format of ['csv', 'json', 'epw', 'basic'] are available.

I suggest that we drop support for the 'basic' output format as there is no point to it; the file type is the same as the csv option but without any header or metadata. For this reason, the file option is also not available on the pvgis web interface and is already not supported by pvlib's pvgis_hourly functions.

The motivation is to reduce the maintenance burden, as dropping support for this file format reduces the code complexity significantly without any drawbacks for users. I'm currently planning more changes to the pvgis functions, but would like this change to be merged first. The planned changes mostly involve changing the outputs to be (data,meta) to be consistent with the rest of the iotools.

[kandersolar]

I think there is no technical barrier to deprecating outputformat='basic' for a while before removing it altogether. However, I bet basic is hardly used, so for the sake of expediency and not taxing @AdamRJensen's patience, I am okay with no deprecation period here, although I grumble nonetheless.

I did not do a thorough review, but these changes seem okay to me (assuming nobody objects to removing basic in the first place). A couple small notes below.

[AdamRJensen]

I think there is no technical barrier to deprecating outputformat='basic' for a while before removing it altogether. However, I bet basic is hardly used, so for the sake of expediency and not taxing @AdamRJensen's patience, I am okay with no deprecation period here, although I grumble nonetheless.

I am planning other breaking changes (consistent output of (data,meta)) which cannot have a deprecation period. So since these functions will be affected by a breaking change in the next release, it's better to include this breaking change too; which would minimize the number of times users would potentially need to update their code.

@mikofski It would be great if you review this since you're the original author!