Create PiecewiseLinearData conversion functions

[jd-lara]

…pData

Add bidirectional conversion capabilities:

• PiecewiseStepData(::PiecewiseLinearData): converts by computing slopes (derivative)
• PiecewiseLinearData(::PiecewiseStepData, initial_y): converts by running sum (integral)
• Corresponding Base.convert methods for both directions

The initial_y parameter allows preserving the y-offset when converting back from step data to linear data.

[github-actions]

[JuliaFormatter] _{reported by reviewdog 🐶}

Suggested change

	(0.0, 0.0), (1.0, 1.0), (2.0, 4.0), (3.0, 6.0), (5.0, 10.0)
	(0.0, 0.0), (1.0, 1.0), (2.0, 4.0), (3.0, 6.0), (5.0, 10.0),

[GabrielKS]

This functionality already exists one level up, i.e., you can already convert an InputOutputCurve that contains a PiecewiseLinearData to an IncrementalCurve that contains a PiecewiseStepData.

I believe that that's the more natural place to put this functionality, because a PiecewiseStepData does not inherently have any relationship to a PiecewiseLinearData, the derivative/integral relationship is only because these are often used to represent IOCs/ICs.

I would be very open to considering extensions of the ValueCurve interface to make those existing conversions easier to call, they are somewhat deliberately hard to call right now because of @jd-lara's expressed aversion to these conversions.

[jd-lara]

@GabrielKS I am trying to figure out a reasonable set of utilities to handle the need for conversions mostly for internal handling in PSI. I don't think we should do that inside of the modeling library and given the need to have some utility to clean datasets I am revising my position.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 80.32%. Comparing base (0ee9770) to head (fca1f55).

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #512      +/-   ##
==========================================
+ Coverage   79.10%   80.32%   +1.22%     
==========================================
  Files          71       71              
  Lines        6192     6115      -77     
==========================================
+ Hits         4898     4912      +14     
+ Misses       1294     1203      -91     

Flag	Coverage Δ
unittests	80.32% <100.00%> (+1.22%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
src/function_data.jl	99.58% <100.00%> (+1.32%)	⬆️

... and 29 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[GabrielKS]

@GabrielKS I am trying to figure out a reasonable set of utilities to handle the need for conversions mostly for internal handling in PSI. I don't think we should do that inside of the modeling library and given the need to have some utility to clean datasets I am revising my position.

That makes sense — I think we should still probably do this only at the ValueCurve level. If your FunctionData fundamentally represents an InputOutputCurve, ideally it would be represented as an InputOutputCurve all along, but in cases (e.g., time series :( ) where that's not possible, I'd recommend upgrading to ValueCurve on the fly to take advantage of these idiomatic conversions that automatically handle the initial input, etc.:

[jd-lara]

closing after @GabrielKS comments.