Add support for cadence-based uprating

[anth-volk]

What's changed

Fixes #158. This PR introduces a new schema to the uprating value within parameter definitions to allow cadence-based uprating (e.g., to allow a parameter in April 2024 to be uprated against the inflation rate between Oct. 2022 and Oct. 2023). For this example, the schema would follow the below format:

uprating:
  parameter: uprater
  at_defined_interval:
    start: 0000-10-01
    end: 0001-10-01
    enactment: 0002-04-01

This would dictate the uprating method to calculate the rate of change for a given parameter between October of year 1 and October of year 0 (i.e., October 2023 and October 2022), then apply that increase on April 1 of year 2 (i.e., April 2024). The schema also includes two optional values:

• interval, which defaults to "year", that defines the uprating periodicity; under "year," uprating would occur every April 1 for the example
• effective, which defaults to the first date not in the original parameter that satisfies the enactment value; e.g., if our sample parameter had a defined value in March 2023, effective would default to April 2023, but if it had a defined value in April 2023, it would default to April 2024

Bug fix

• Regression test added
• Regression test passing

What this fixes and how it's fixed

This allows for the calculation of cadenced uprating parameters, such as the UK Government's inflation uprating.

If the parameter contains the "at_fixed_interval" key, a function is called that composes a dict of settings to be used later, checking each setting for validity at that time.

Afterwards, two functions determine the date upon which to start and stop uprating, then another uses the rrule package to determine how many uprating intervals occur between these two dates; this will typically default to how many years occur, but can be set by the user.

The same function determines the distance between the fixed interval measurement's "start" and "end" values, on the one hand, and the "enactment" value on the other (e.g., if "start" is 0000-10-01 and "enactment" is 0002-04-01, it determines the distance between these dates). It then calculates the percent change between "end" and "start" and saves this to a dict, with they key being the "enactment" date.

Finally, another function uses this uprater-by-multiplication dict to uprate cumulatively, as opposed to the uprating function's current structure, which uprates everything against the last defined value in the parameter that is to be uprated.

[codecov]

Codecov Report

Attention: Patch coverage is 90.87452% with 24 lines in your changes are missing coverage. Please review.

Project coverage is 82.89%. Comparing base (e206491) to head (ef09d5b).

❗ Current head ef09d5b differs from pull request most recent head 1d14935. Consider uploading reports for the commit 1d14935 to get more accurate results

Files	Patch %	Lines
...ne_core/parameters/operations/uprate_parameters.py	87.41%	9 Missing and 10 partials ⚠️
policyengine_core/taxscales/tax_scale_like.py	40.00%	3 Missing ⚠️
policyengine_core/parameters/at_instant_like.py	50.00%	1 Missing ⚠️
policyengine_core/reforms/reform.py	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #173      +/-   ##
==========================================
+ Coverage   82.59%   82.89%   +0.30%     
==========================================
  Files         186      186              
  Lines        9016     9227     +211     
  Branches     1133     1158      +25     
==========================================
+ Hits         7447     7649     +202     
- Misses       1302     1310       +8     
- Partials      267      268       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.