[DEV WORKFLOW]: Deprecation removal claims are not enforced in pvlib's lifecycle

[echedey-ls]

Is your feature request related to a problem? Please describe.
Frustration kicks in when I find deprecated features that were supposed to be removed in the past. It's like, am I browsing someone's branch not up-to-date? Do I have some virtual environment with a pvlib fossil installed? The answer is, no, it's just some legacy deprecated code still there!

Jokes aside, here are some examples found on the wild of issues reporting forgotten removals:

• [DEPRECATION]: pvlib.iotools.read_tmy3 deprecated recolumn parameter removal scheduled for v0.11.0, still there #2324
• Deprecated pvsystem.sapm_spectral_loss not removed #2243 (TBF this one didn't claim any removal version, just stated soon after its announcement in v0.10.0)
• Deprecated pvlib.atmosphere.first_solar_spectral_correction not scheduled for removal #2130 (same as previous)

Describe the solution you'd like
Any procedure that avoids forgetting them. The best one that comes to my mind right now is:

1. Create issues immediately after a PR introduces a deprecation, label and milestone them appropriately:
   1. Requires creating more version milestones.
   2. I'd love labels for them, at least deprecation. May consider others as well.
2. Require @fail_on_pvlib_version in warning tests in the PRs introducing the deprecation, so tests fail when pvlib gets to the scheduled removal version.
3. Add or modify PR template to remind contributors and maintainers.

Describe alternatives you've considered
a. Add a label introduces deprecation to easily browse which PRs may need a follow-up.
b. Keep the original issue of the PR introducing deprecations open, and reassign milestone. (-1)
c. Rely on the quality testers (i.e., users (i.e., do nothing)) (-1)

Additional context
I fear the same outcome for:

• Change g_poa_effective to effective_irradiance #2235
• Adopt dni_clear variable name for clearsky DNI #2274
• Adopt ghi_clear variable name for clearsky GHI #2306.

Feel free to weight in, specially if you know of other alternatives :D

[kandersolar]

SciPy has a pinned "deprecation tracker" issue. I've never opened it up to look at it, but perhaps looking at their process would be instructive for us.

[AdamRJensen]

Potentially we could create an issue that acts as a deprecation tracker for each upcoming major version? A bit like the release planning issues, but created much earlier