Register solution as a Feature with separate node/edge keys

[cmalinmayor]

Summary

• Rename graph attribute "solution" to "node_solution" / "edge_solution" with pl.Boolean dtype (was pl.Int64)
• Add Solution(feature_type) factory function returning a boolean Feature
• Register both as proper Features in the FeatureDict via _get_feature_set
• Simplify DeleteEdge to save/restore edge attributes generically via the edge_features loop (same pattern as DeleteNode)
• Remove hard-coded solution saving from DeleteNode (now captured by node_features loop)
• Handle v1 format backward compatibility by renaming old "solution" keys on load

[codecov]

Codecov Report

❌ Patch coverage is 86.48649% with 5 lines in your changes missing coverage. Please review.
✅ Project coverage is 93.20%. Comparing base (3ae556a) to head (75ecf32).

Files with missing lines	Patch %	Lines
src/funtracks/import_export/_v1_format.py	68.75%	5 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #223      +/-   ##
==========================================
- Coverage   93.29%   93.20%   -0.10%     
==========================================
  Files          59       59              
  Lines        3220     3236      +16     
==========================================
+ Hits         3004     3016      +12     
- Misses        216      220       +4     

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

🚀 New features to boost your workflow:

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

[TeunHuijben]

@cmalinmayor, I like a lot how much simpler the actions become by having solution as a normal Feature! 😍

For my understanding, what is the main reason for this change, in contrast to leaving the solution keys we had and making them a funtracks Feature? I can see how having the same feature name on nodes and edges is confusing in the funtracks Features world, but I am wondering which of the two is preferred. A reason for keeping the td solution key is that it works natively with tracksdata functions, without having to indicate which column represents the solution.

Another consideration is that this change loses the ability to use tracksdata solvers. Meaning that it will be harder to use a td solver on a td.Graph in funtracks. The main reason is that the solver returns a single output/solution key for nodes and edges, where funtracks requires different keys (a simple rename afterwards would do the job though, so probably not that big of a problem in retrospect). Since we will be using motile for solving, it should be fine. But I am wondering how close we should stay to the native “solution” logic of tracksdata.