Define JSON and SQL migrations via functional programming approach

[crschardt]

Description

What changed?

This is a rewrite of #2594 with a functional programming approach to cut down on the Java boilerplate and make it easier to remove steps when they are no longer needed.

Why?

Explain the reasoning and any issues this addresses

Testing

• I have tested this change locally
• Test evidence (screenshots, videos, or test results):

Paste screenshots or video links here

Related Issues

Closes #

---

AI Disclosure

• This PR was authored entirely by me
• This PR includes AI-generated code (e.g., from GitHub Copilot, ChatGPT)
  • If yes, I have reviewed all AI-generated code for correctness
  • If yes, please describe which parts were AI-assisted:

Describe AI involvement here if applicable

---

Merge Checklist

• PR title is a short, imperative summary of changes
• PR description documents the what and why

Additional Checks (if applicable)

• User-facing changes? User documentation is updated
• Breaking changes? Migration guide is included in description and migrations are marked with // MIGRATION: <dataYear> where <dataYear> is the last season the pre-migration data was used in
• Bug fix? Regression test is added
• New dependency? License compatibility is verified and steps have been taken to follow it
• Serde changes? All messages are regenerated with no unexpected hash changes
• Configuration changes? Changes are backwards compatible with previous season's last release
• Pipeline/data exchange changes? Frontend types are updated in ./photon-client/src/types