Follow dask task API more closely?

[khaeru]

Building on #149:

Dask recently introduced an internal classes like GraphNode, Task, etc. and uses these in its internal graph representation. This mirrors in some ways handling done in genno and downstream, e.g. message_ix_models.workflow.Step. For instance, it reflects a need or desire to attach the key to the task directly (rather than having (key, task) pairs only via a container like a dict).

We could consider whether to:

• Generate dask.Task items within genno, so that dask's internal convert_legacy_graph() call does not need to transform the genno.Computer.graph.
• Adjust genno.Key to be a subclass of one of the dask.typing.Key classes: str, bytes, float, int, or tuple of same. For instance, Key could be made a subclass of tuple with contents (name, (dims,), (tags,)).

However, most of these features are not advertised as part of the documented/public dask API, so it may be unwise to rely on their stability. Another approach (probably not desirable, because of maintenance overhead) would be to vendorize parts of dask that are used by genno.