GraphBuilder->Graph with separate Workflow type

[acl-cqc]

• Add parametrized Workflow holding a GraphData and outputs_type.
• GraphBuilder renamed to Graph, and .outputs renamed to .finish_with_outputs which returns a Workflow
  • TODO: Rename finish_with_outputs to build??
• Change methods that take Graph(Builders) (e.g. loop, eval) to take Workflow's, removing check in embed that the Output node is present (this is now guaranteed if your python code is well-typed - I was surprised not to find more such checks in map/loop/eval/const/etc.)
• Add a ModelConvertible protocol like DictConvertible/etc. but that works for parametrized types. (This was a bit of a can of worms, there are some slightly suspect bits in types.py.) Workflow implements this, and serializes as a GraphData. (Type erasure: Workflow is a build-time-only construct).
  • This was in commit 6ccf080, previously I included Workflow in the union of PType's which was a bit hacky (special-case, awkward circular import, etc.) but a lot shorter/easier (and DictConvertible makes me worry about robustness and parametrization). Thoughts?
• Update stub generator to support TNamedModel's as well as PModel Structs (by adding an is_ptype field to GenericType - this is not super-neat, suggestions of better ways to do this welcome, but my previous attempt was even (much) worse]: 454c18f)
  • It'd be good to remove @runtime_checkable from the RestrictedNamedTuple subclasses/instantiations, but leaving that for Another PR
• Update test functions, docs/notebooks, etc., and test worker (including tests from tests: more fun with workers making graphs #392) to take/return parametrized Workflow rather than GraphData. This was a bit tedious, and the bulk of changed files in the PR...
  • TODO: there are probably some doc updates to be made here describing how to use the new API

The end result is that you need fewer TypedGraphRefs (but still some), and when you do need one, pyright should catch cases of providing the wrong outputs_type (because this is now just a runtime reification of a type that pyright knows statically).

Other possible TODOs (maybe too much for one PR??)

• Remove output type from GraphBuilder (and provide when you set the outputs), adding a subclass RecursiveGraphBuilder that requires setting the output-type at the start (with fn graph_ref(self) moved into this Recursive variant)
• We have quite a few tests that build GraphData's directly (not using the builder)....if we want the builder to be the only supported way of building graphs, we'll need to update these too.
  • If we do that, then this would allow hiding GraphData (i.e. making private, this is python) where it is used in the builder, so GraphData is really part of the graph runtime, not part of the user-facing graph-building API.

[acl-cqc]

Hmmm I mean do we need these :types? Are they not inferred from the type annotations?

[acl-cqc]

I'd +1 this, shall I do it in this PR?

[rossduncan]

Why do we need both FinishedGraph and GraphData ?

[acl-cqc]

Why do we need both FinishedGraph and GraphData ?

As per last paragraph in the description (TODOs/future work):

• We have quite a few tests that build GraphData's directly (not using the builder)....if we want the builder to be the only supported way of building graphs, we'll need to update these too.
  • If we do that, then this would allow hiding GraphData (i.e. making private, this is python) where it is used in the builder, so GraphData is really part of the graph runtime, not part of the user-facing graph-building API.

I.e. I think we need GraphData as an internal struct, for (a) serialization, and (b) passing from GraphBuilder into FinishedGraph, but we could hide it from the user with more updates to tests etc. Except this may restrict partial in the future, we should do a bit of investigation.