Closes #1424

Changes proposed in this Pull Request

This PR fixes several issues we have in ramping constraints. Citing @lkstrp, it is another case of our very annoying p == p0 but != p0

the original point was whether p0 here is redundant:

A: No. Although during optimization it indeed -p (dynamic attribute p0 does not exist at point of optimization and is created after solve in assign_solution). However, there is a case when define_ramp_limit_constraints is applied in rolling horizon mode. In this case we have to refer to previous period's dispatch (stored in p0 for a Link specifically).

• One problem here that our lovely test suite never had Link & ramp_limits together.
• If I add such test, the constraint breaks because of a buggy logic: c.dynamic.keys() assumes that at least one of {"p", "p0"} there, but on the first optimization run, nothing exists yet in the dynamic data for Links.
• Furthermore, the constraint breaks also in a standard n.optimize() call (w/o RH) because function tries to access p0 before checking whether we are at all in the rolling horizon mode.
• And finally, docstring is wrong. Ramping limits are applied to attributes that have ramping attributes, which are only Generator and Links.

Checklist

• Code changes are sufficiently documented; i.e. new functions contain docstrings and further explanations may be given in docs.
• Unit tests for new features were added (if applicable).
• A note for the release notes docs/release-notes.md of the upcoming release is included.
• I consent to the release of this PR's code under the MIT license.