Split FinishedGraph off from GraphBuilder, return from worker

[acl-cqc]

• Add FinishedGraph holding a GraphData and outputs_type.
• GraphBuilder.outputs renamed to finish_with_outputs and returns a FinishedGraph
• Change methods that take GraphBuilders (e.g. loop, eval) to take FinishedGraph'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 FinishedGraph as a PType (GraphData already is), and serialize FinishedGraphs as GraphDatas in the runtime. (That is, they are a build-time-only construct).
  • TODO: this could be done better, by defining a ModelConvertible or similar in types.py implemented by FinishedGraph (which then is used only in the builder and worker IDL).
• 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 FinishedGraph rather than GraphData. This was a bit tedious, and the bulk of changed files in the PR; also suggests this might be the time to do the grand renaming in that I'm already writing e.g. workflow = g.finish_with_outputs(...)

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)
• Renaming could take place here: FinishedGraph -> Workflow, GraphBuilder -> Graph, finish_with_outputs -> finish/compile/into_workflow/???
• 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]

This has probably just broken visualization of half-built/in-progress graphs. I might need to take a GraphData | GraphBuilder | FinishedGraph here (and bring back some way to get_data the GraphData out of a GraphBuilder)

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