Add extreme BSRN QC limits

[AdamRJensen]

• [ ] Closes #xxx
• [ ] Added tests to cover all new or modified code.
• Clearly documented all new API functions with PEP257 and numpydoc compliant docstrings.
• [ ] Added new API functions to docs/api.rst.
• [ ] Non-API functions clearly documented with docstrings or comments as necessary.
• Adds description and name entries in the appropriate "what's new" file
  in docs/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`).
• Pull request is nearly complete and ready for detailed review.
• Maintainer: Appropriate GitHub Labels and Milestone are assigned to the Pull Request and linked Issue.

The QCRad software relies on the BSRN irradiance limits. Specifically, QCRad uses the "physical possible" BSRN limits for the upper limit but both the "physical possible" and the "extremely rare" BSRN limits for the lower limits. Currently, pvanalytics only support the "physical possible" limits.

However, the "extremely rare" limits are widely used, e.g., by Espinar et al. (2011), Geuder et al. (2015), Lorenz et al. (2022), and Forstinger et al. (2021).

In this PR I propose adding the "extremely rare" BSRN limits to the QCRad functions. Ideally, I think the functions should be named "_bsrn and not "*_qcrad" as QCRad states that it relies on the BSRN limits. At the current stage, the PR isn't breaking anything, but changing the function names would of course be a braking change.

[AdamRJensen]

These lines could also be deleted, and thus pass the limits parameter directly to the individual QC functions. The functionality would be the same and I think it would be more intuitive.

[cwhanse]

I propose adding the "extremely rare" BSRN limits to the QCRad functions.

+1 to this. What do you think about extending the output to a tuple (boolean series, integer series) as is being done in #167?

Ideally, I think the functions should be named "_bsrn and not "*_qcrad" as QCRad states that it relies on the BSRN limits.

On reading that paper again, I agree. We can deprecate the existing functions and use _bsrn for functions that introduce the option to evaluate extremely rare value limits. We can address #191 in the new functions also.

[AdamRJensen]

+1 to this. What do you think about extending the output to a tuple (boolean series, integer series) as is being done in #167?

I'm not sure I see the advantage of having two outputs?

On reading that paper again, I agree. We can deprecate the existing functions and use _bsrn for functions that introduce the option to evaluate extremely rare value limits. We can address #191 in the new functions also.

Yay! 😄