`filewriter`: `selog/EPICS_PUTLOG`

The current `.nxs` files contain the EPICS putlog as a string-typed `selog` entry.

The baseline assumption is that the putlog entries will be streamed to a dedicated Kafka topic as a [`vs00`](https://github.com/ess-dmsc/streaming-data-types/blob/master/schemas/vs00_strings.fbs) or similar schema, by some separate process to-be-written.

This requirement is low-priority for the immediate future, but we should still consider supporting it long term.

## Questions

The ISISICP currently writes strings in a way that is not nexus-compliant.
* Do we want to continue to do that?
* There is a new NXtextlog nexus class for storing string-logs: https://github.com/nexusformat/definitions/pull/1590 . But will using that cause problems for Mantid?

## Potential differences from existing files

- Some of the PV names (particularly the DAE PVs) will be different in the datastreaming system, and may not be captured in the CA putlog as they are served over PVA instead. For example if downstream analysis is expecting to be able to parse strings like `Changed PV: IN:SANS2D:DAE:BEGINRUNEX new=0 old=0 ` from this log, then that would no longer be valid.

Start by examining how the current .nxs files represent the string-typed selog EPICS putlog, then compare the proposed vs00 Kafka representation with the NXtextlog Nexus class. Resolve whether the format remains Nexus-compliant and compatible with Mantid, including the listed PV-name differences; done means the long-term storage and streaming approach is decided.

Vom Indexierungsmodell aus dem Issue-Text verfasst.