Improve pvlib.spa speed

[kandersolar]

• I am familiar with the contributing guidelines
• 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`).
• 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.

Some functions in pvlib.spa are doing quite a lot of unnecessary computation:

• For the table-based computations, our code combines arrays of different lengths into a single 2d array, thus padding the shorter arrays with zero, and creating a bunch of unnecessary busy work to process those dummy entries.
• The longitude_nutation and obliquity_nutation functions perform the same expensive calculation
• To much lesser effect, there are several instances of a single function containing multiple calls to np.radians(x).

This PR prevents those unnecessary computations and reduces overall calculation time by 40-50% for both numpy and numba. The table below compares runtimes in seconds:

n	numpy, PR	numpy, main	numba, PR	numba, main
10	0.002	0.004	0	0
100	0.003	0.004	0	0.001
1000	0.006	0.011	0.001	0.002
10000	0.041	0.069	0.009	0.017
100000	0.4	0.657	0.083	0.161
1000000	4.654	8.492	0.864	1.633

Regarding the table-length issue, it might be better to do away with the combined HELIO_LONG_TABLE et al. entirely and just keep the arrays as separate module-level variables.

[kandersolar]

Ready for review. The drop in reported coverage should be ignored; it's in the part of pvlib.spa that is run in numba-mode only, and coverage tracking doesn't work with numba functions.

[wholmgren]

Great work @kandersolar!

[wholmgren]

Do we need to declare types in this jcompile like we do in most of the other functions in this module? I haven't kept up with numba development.

[kandersolar]

I'm not an expert here either, but I think specifying types is not necessary in general; when using numba for JIT compiling like we do, it can infer types as needed.

In this particular case, I did try to specify types just for consistency with the rest of the code. However it seems that specifying the appropriate type for module-level array constants is not possible using the shorthand string notation. It is possible by importing numba, but I didn't see a clean way to no-op the type declaration when numba isn't installed, so I opted to just leave the type signature empty here instead. I've added a comment along these lines (should have done that originally).

[wholmgren]

There's also pvlib.solarposition.spa_python and ModelChain.run_model*. Maybe less is more in this situation: The default solar position algorithm (NREL SPA) is now 50-100% faster.