`filewriter`: `instrument` group

Things under `raw_data_1/instrument`.

## Potential differences from existing files

- `source/type` - propose to write strings that match the upstream [nexus NXsource standard](https://manual.nexusformat.org/classes/base_classes/NXsource.html) i.e. `Spallation Neutron Source` instead of `Pulsed Neutron Source`.
- `source/probe` - propose to write strings that match the upstream [nexus NXsource standard](https://manual.nexusformat.org/classes/base_classes/NXsource.html) i.e. `neutron` instead of `neutrons`.
- `dae/detector_table_file`: `detector.dat` doesn't exist in new system. We can either write a blank entry, or not write it at all.
- `spectra_table_file`/`wiring_table_file`: will point at a differently-formatted file, and this file will likely not be accessible from NDX. If the files are hosted centrally (e.g. git), we could point this at a git URL if needed. Does anything currently expect to be able to parse the files given in these filepaths?
- `dae/time_channels_/time_of_flight_raw` & `detector_/time_of_flight_raw`: data in cycles of a 32MHz clock. This doesn't make sense in streaming system. We can back-calculate it from data in `ns` if required. Do we need to write it?
- `dae/vetos`: There will be more vetos, and with different names, in the streaming system.
- `dae/type`: Will be something other than `ISIS_DAE3`. To-be-determined exactly what.
- `dae/detector_/polar_angle` & `dae/detector_/distance`: the streaming system currently doesn't know about geometry information. Do downstream consumers require these?

Start by inspecting the raw_data_1/instrument group, especially the source and dae entries listed in the issue. Check the NXsource standard and determine whether downstream consumers depend on the referenced table files, raw time-of-flight values, vetos, or geometry fields. Done means the required fields and streaming-system values are agreed and documented.

Written by the indexing model from the issue text.