These mostly use the same algorithm as the one in graphBuilder.py, but
they split the pipeline up into disconnected subgraphs first, which
will provide a nice performance boost for some pipelines.

The other algorithmic difference is that pruning via adjustQuantum now
happens directly in QG generation, making the stuff for pruning in
QuantumGraph construction unnecessary, and allowing adjustQuantum to
raise NoWorkFound even during QG generation.

By building on PipelineGraph's more careful handling of storage class
overrides, this should make it much, much harder for those problems to
creep back in.

And finally, the split here into an ABC and implementation should make
it much easier to handle special QG generation cases, like the ones
for gathering resource usage and HiPS generation, as they can now
delegate the stuff they don't want to customize to the base class.
This may be useful for generating simple QGs in Prompt Processing, too
(but I'm not convinced it'd gain us much) or as a starting point for a
more advanced general-purpose QG generation algorithm (though it's
unlikely the base class could stay _exactly_ as is for that.

It's easier for a user who wants to adjust verbosity to only deal with
one logger for all of QG generation.

We're always comparing data IDs with the same dimensions, so we can
do it much faster by just comparing value tuples.

Make use of the butler serialization caching mechanisms to make
sure object are effectively cached instead of reconstructing
objects needlessly. Also lower the compression ratio of LZMA.
This results in slightly larger graph sizes, but is offset by
a large runtime gain.

QuantumGraph doesn't need to be able to prune itself anymore, since
that's now handled earlier, inside QuantumGraphBuilder (where we can
do it more efficiently).

And without that pruning code, it's easy to replace QuantumGraph's
_datasetRefDict attribute with a temporary networkx graph, and this
sidesteps a problem in which different DatasetRefs don't compare as
equal if they have different storage classes, which was causing QGs to
lack some edges they should have had with the QuantumGraphBuilder.  I
believe this was because the old QG generation algorithm passed
DatasetRefs with incorrect storage classes to QuantumGraph, and that
also sidestepped the bug.

This class was previously used for both task <-> dataset type graphs
and quantum <-> dataset graphs, and now it's just used for the former.
So it doesn't need to be generic, and it doesn't need to support node
removal anymore.

Eventually it should be replaced entirely by PipelineGraph, but that's
out of scope for now (it's part of DM-40442).

With the switch to tuples instead of DataCoordinates as keys, adding
nodes implicitly when edges are added gets trickier; we can only
support it for input datasets, because something else (registry queries
or upstream tasks) are responsible for making DatasetRefs for those.

We want to allow users to include at least the output run here without
it actually existing yet, and let that be a no-op, instead of
complaining.