Add XSPEC model string macro (closes #187)

[aditya-pandey-dev]

Implements bidirectional translation between XSPEC model strings and
XSPECModels.jl types, as requested in #187.

Changes

• lib/XSPECModels/src/xspec_string.jl — new file:

  • parse_xspec_model_string(str): runtime XSPEC string → Julia Expr
  • xspec"..." string macro: compile-time, zero overhead
  • xspec_model_string(model): reverse direction
  • XSPEC_MODEL_NAMES: 20 verified model mappings

• lib/XSPECModels/src/XSPECModels.jl — include + export new API

• lib/XSPECModels/test/test-xspec-string.jl — full test suite

• lib/XSPECModels/test/runtests.jl — include new tests

• docs/src/transitioning-from-xspec.md — complete guide for XSPEC users

• docs/make.jl — add page to navigation

• docs/src/models/xspec-models.md — mention new feature

• running_example_xspec_strings.jl — self-contained demo

Example

model = xspec"phabs*powerlaw"
model = xspec"tbabs*(diskbb+powerlaw+gaussian)"

xspec_model_string(XS_PhotoelectricAbsorption() * XS_PowerLaw())
# "phabs*powerlaw"

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 57.49%. Comparing base (62aba68) to head (551cb1c).

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #242      +/-   ##
==========================================
+ Coverage   55.69%   57.49%   +1.79%     
==========================================
  Files          39       39              
  Lines        2632     2550      -82     
==========================================
  Hits         1466     1466              
+ Misses       1166     1084      -82     

☔ 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.

[aditya-pandey-dev]

@fjebaker I have raise a PR related to this issue can you please review the PR

[fjebaker]

Hello @aditya-pandey-dev thanks for your PR! I am away at a conference this week so it will take me some time to review this.

[fjebaker]

I've had a look through this and very strongly suspect this was predominantly written by an LLM. There is so much here that I would ask you to address but it's not a good use of my time or yours to iterate on a review cycle this way.

If you do want to work on this issue, please try to implement this yourself. I am happy to spend my time reviewing code that you personally wrote and have opinions on, and can modify in small and meaningful ways, than have every comment I suggest result in an LLM rewriting vast amounts of the code that exponentially inflates the time I have to spend reviewing.

What this PR currently would introduce would be a huge maintenance task to keep going when new models are introduced or bugs are found. The test set is so brittle that the implementation has very little flexibility, which isn't good for a package that is still under development. LLMs write code that only another LLM can maintain. That is not in line with the ethos of SpectralFitting.jl or GSOC.

[aditya-pandey-dev]

Hi @fjebaker,
Thank you for the honest feedback. You are right,
and I sincerely apologize. i rewrite the code again