Add out_of_bounds parameter to irradiance QC tests

[AdamRJensen]

• Closes Values outside QC test domain are incorrectly flagged as in error #191
• 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.

This PR adds an optional out_of_bounds parameter to the irradiance QC tests which allows the user to specify whether to Fail (False) or pass (True) a test when the conditions are outside of the valid test domain.

[AdamRJensen]

@cwhanse, @kandersolar, @kperrynrel Before completing this I'd appreciate a review of the parameter naming and implementation and whether you can support this for future irradiance QC tests

[cwhanse]

The definition of out_of_bounds confuses me: "Whether a test is failed (False) or passes (True) when test conditions are not satisfied." If the test is not satisfied, and the function returns True, what is the point of doing the test?

If instead, you want the control the internal workings of the test, and not apply the GHI and zenith bounds, then "skip_bounds=False" makes more sense to me.

[AdamRJensen]

The definition of out_of_bounds confuses me: "Whether a test is failed (False) or passes (True) when test conditions are not satisfied." If the test is not satisfied, and the function returns True, what is the point of doing the test?

If instead, you want the control the internal workings of the test, and not apply the GHI and zenith bounds, then "skip_bounds=False" makes more sense to me.

My earlier definition probably wasn't good. The following is probably better:

outside_domain_value : default False
    Value to return when the tests are not applicable, i.e., when the
    inputs fall outside the test domain.

What I'm trying to achieve is that a test isn't considered failing when the test conditions aren't met (e.g., irradiance is below 50 W/m^2). @cwhanse does this make more sense?

[cwhanse]

That makes sense now. "out_of_domain" works for me, "out_of_domain_value" seems like the "value" part is optional.

[AdamRJensen]

@cwhanse @kandersolar This PR is ready for review.

Cliff suggested naming the new parameter out_of_domain, whereas I have named it outside_domain - let me know if you have preferences.

[cwhanse]

My browser GH is behaving strangely so if the suggested changes look wonky, its not me.

[cwhanse]

Suggested change

	inputs fall outside the test domain.
	irradiance or zenith values fall outside the test domain.

[AdamRJensen]

I think @kandersolar was against listing the specifics. I somewhat agree, as "irradiance values outside the test domain" might be confused as to above/below the threshold. Not a strong feeling though.

[cwhanse]

OK. I'm OK with "data" instead of "inputs".

[cwhanse]

Add "r" to the line below so that the math equations render.