Would this PR break anything for users or just internally in the downstream packages?

This would not break (I mean breakage would be internal) workflows/notebooks where an instrument configuration is used to select the tof LUT (as is done in Dream).
It would break e.g. the Bifrost workflow.

Is there a way to avoid running the simulation twice, once for sample and once for, e.g., vanadium? Without an intermediate file, that is?

Not sure it's easy to do automatically. You'd have to compute the SimulationResults[SampleRun] and then set
wf[SimulationResults[BackgroundRun]] = wf.compute(SimulationResults[SampleRun])
and then the same again for EmptyBeamRun.

Maybe this is a sign that it's turning out to be a bad idea?
I guess when we load the table from a file, the file is loaded multiple times, but this is cheap compared to running the simulation?

One option would be to have types like GenericSimulationResults and default providers that convert those into SimulationResults[RunType], etc. But this would double the size of the tof graph.

Loading from file is probably fast enough because the tables are fairly small. In practice, that is probably what we would use most of the time, right? We would usually not run a simulation during reduction? So we could just leave it as is and see if we get into performance problems.

Is there a way to have a function take in DiskChoppers[RunType] where we would loop over all the run types and check that all chopper settings are the same, and then return a single Choppers (or a better name) which does not depend on RunType?

Is there a way to avoid running the simulation twice, once for sample and once for, e.g., vanadium? Without an intermediate file, that is?

Note that after the update, we can either:

wf = GenericTofWorkflow(tof_lut_provider=TofLutProvider.TOF, ...)
table = wf.compute(TimeOfFlightLookupTable[SampleRun])
for run in (SampleRun, BackgroundRun, OpenRun):
    wf[TimeOfFlightLookupTable[run]] = table

wf = GenericTofWorkflow(tof_lut_provider=TofLutProvider.FILE, ...)
# Compute from simulation is still possible
table = wf.compute(TimeOfFlightLookupTableFromSimulation[SampleRun])
wf[CommonTimeOfFlightLookupTable] = table

But I am still wondering if it might be better to just not really support the TofLutProvider.TOF in the main workflow at all, and instead have it as a separate workflow that can compute a lookup table.

This is replaced by #253