Use Hottel's method for bifacial.utils.*_integ functions

[kandersolar]

• Closes #xxxx
• 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.

I realized that our integrated view factor calculations are equivalent to what is calculated using Hottel's crossed strings method. The calculations are straightforward, closed form, and much faster than numerical integration. Here is a speed comparison for the ground->sky view factor:

And since vf_ground_sky_2d_integ is the main bottleneck in infinite_sheds.get_irradiance, runtime improves there by 1-2 orders of magnitude as well.

PR is marked as draft while the code is a mess.

[mikofski]

FYI: there’s another pvlib issue with links to recent uses of Hottel’s crossed strings in the literature, one of the main advantages being its easy application for PV on slopes.

One disadvantage may be that we lose view factor as a function of location on the ground which could be reused in Marion’s model.

[kandersolar]

One disadvantage may be that we lose view factor as a function of location on the ground

I don't see any reason not to retain the current vf(x) functions. This PR only changes how the _integ() functions are computed internally.

[echedey-ls]

Suggested change

	def test_vf_ground_sky_2d_integ_deprecated():
	@fail_on_pvlib_version(...)
	def test_vf_ground_sky_2d_integ_deprecated():

Let's make sure docs and code gets cleaned in the future? v0.12 or v0.13, whatever feels right. I would also add the future version to deprecate in the docs admonition.