Type and documentation improvements to JSON-LD API

[multimeric]

Summary of changes

All these changes should have no impact at runtime, they're purely to improve UX through static analysis.

• Convert Term to a typed NamedTuple from a namedtuple. This makes static analysis easier in that your IDE and type checker can understand which fields are present on the type, the type of each field, and give each field its own documentation
• Document the meaning of each field in Term for usability
• Move the type definition of Context fields into the class body. This is also for static analysis and allows the user to get tab completion etc when using these fields.

My long term goal is to make this context API usage as a public API, so that I can generate and interact with contexts programmatically instead of just by defining these in JSON.

Checklist

• Checked that there aren't other open pull requests for
  the same change.
• Checked that all tests and type checking passes.
• Considered granting push permissions to the PR branch,
  so maintainers can fix minor issues and keep your PR up to date.

[edmondchuc]

Hi @multimeric, given that your changes have no runtime impacts, would it make sense to target the 7-maintenance branch? If so, we should be able to get this into the next 7.x release fairly quickly.

I tried changing the target branch but unfortunately I think this PR was branched off of main.

[multimeric]

Sure, I can do that.

Any thoughts on exporting Context and Term in somewhere higher level than the plugins module?

[edmondchuc]

No thoughts on lifting types at this time. Most type hints added have been colocated in the same module where they are used, but happy to hear your thoughts if you think there's a better approach.

This is the documentation on typing.

[ajnelson-nist]

@multimeric I think the lift argument is easier to follow if we could see a motivation for it. For instance, I could see some benefit to exposing the JSON-LD context dictionary at a level where the NamespaceManager could interact with it, because I've found myself wanting the context dictionary to fulfill some of the same technical role in prefix assignment as, say, the Turtle preamble. In the context of the current PR, that feature would be out of scope. Do you have a motivation within this PR's scope?

[multimeric]

Well the reason I'm improving the context interface here is so that it can be consumed directly by my code. However, it just kind of feels like Context and Term aren't designed to be a public interface (despite lacking an underscore), because they're buried in submodules. I'm just worried it will get moved at some point in the future.

[multimeric]

Closed in favour of #3201.