Make Task construction more type safe

[knexer]

Lots of experimentation with Bradley determined that doing this 100% is impossible. The best remaining strategy we found is:

• Have task ids be a generic class with a unique identifier plus a return type.
• Remove task constructors, and add factory methods to task graph that take whatever callbacks plus task ids for dependencies.
• A limited number of factory method overloads with static type safety for each task type, e.g. zero dependencies, one dependency, two dependencies.
  • It's a bit combinatoric - three task types, n dependencies, and output task yes or no.
• Task graph factory methods do runtime checks validating type compatibility for added tasks as a fallback if there's no statically checked overload.

The first step would be to add the Task factory methods to the task graph. The next step would be to swap Tasks for task ids.

[knexer]

Took a stab at adding the runtime-type-safe Task factory functions to TaskGraph, and even the reduced runtime-only checking is harder than I expected. There seems to be no supported way to get the generic types at runtime (see here).

Starting from the function registry side of things might be more fruitful. I'm picturing something like:

• Make FunctionRegistry a real class
• Add a class FunctionId, which would have a unique identifier and the type information for a Callable (params and return type)
• Add a class TaskId, which would have a unique identifier and the type information for a Task (output type only)
• FunctionRegistry.add(...) would take a Callable, and return a FunctionId with corresponding type information.
• TaskGraph.add_task(...) would take some FunctionIds and some TaskIds, and return a TaskId for the new task. It would check, at runtime, the type information of the FunctionIds and TaskIds against one another for compatibility.

Random thought: Could FunctionRegistry/FunctionId somehow permit defining a callback that doesn't care about the graph context?