Consider loading detectors and analyzers in a single provider each

Currently, we load all detectors, detector data, and analyzers individually. This means that we have 45*3 distinct file accesses. This is useful when we only want to load a small subset of detectors. But it also causes problems:

• When using a threaded scheduler, there is high contention on the file which slows down the pipeline significantly. It is slower than a single threaded scheduler.
• The pipeline graph is very large and unreadable for all 45 detectors.
• We have to determine and specify the list of detector names when creating the workflow.

We keep the detectors separate for a bit but merge them all into a single data array eventually. I think we can fix all 3 issues by never even mapping the pipeline over detector names. We would have a provider similar to this:

DetectorNames[RunType] = list[DetectorName[RunType] | None

def load_all_detectors(
    location: NeXusAllComponentLocationSpec[NXdetector, RunType],
    detector_names: DetectorNames[RunType],
) -> NeXusComponent[NXdetector, RunType]: ...

where DetectorNames[RunType] defaults to None which means 'load all NXdetectors'. And similarly for analyzers and detector events.

This would still allow us to selectively load detectors but would simplify the normal case of loading all detectors. It would also reduce the size of the pipeline and would strongly reduce contention on the file.

Start by tracing the current detector, detector-data, analyzer, and detector-event providers and the workflow construction that maps over detector names. Compare that structure with the proposed single-provider interfaces and verify that selective loading still works while the all-detectors case reduces file accesses, pipeline size, and threaded contention.