♻️ split off source fields in NeedItem internal data

[chrisjsewell]

The source mapping data (docname, lineno, ...) is now stored in a separate field, which allows for more clarity over the source of the need, allows more source specific information to be stored, and has better type safety.

The users of these objects should see no change in its API

[codecov]

Codecov Report

❌ Patch coverage is 96.77419% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 88.82%. Comparing base (4e10030) to head (8ed6201).
⚠️ Report is 149 commits behind head on master.

Files with missing lines	Patch %	Lines
sphinx_needs/need_item.py	95.45%	3 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1491      +/-   ##
==========================================
+ Coverage   86.87%   88.82%   +1.94%     
==========================================
  Files          56       68      +12     
  Lines        6532     8639    +2107     
==========================================
+ Hits         5675     7674    +1999     
- Misses        857      965     +108     

Flag	Coverage Δ
pytests	88.82% <96.77%> (+1.94%)	⬆️

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

☔ 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.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[ubmarco]

Why would the need_type have a default? Isn't that required primary information when using the API?
For the title I remember it can potentially be generated from other sources.

[chrisjsewell]

So this was only because the docname and lineno were already before these arguments, and I can't add defaults for these without adding defaults for the others. Otherwise I have to change the order and potentially break user code already using add_need as it currently is (if they are not using keyword arguments)

[ubmarco]

Ok got it. I see in generate_need (which is called by add_need), that the given need type is checked against the registered types and errors if it does not match, so I'm ok with that.

[ubmarco]

I like the new need source implementation. It's the better structure to know where information comes from.