`filewriter`: Neutron event data (`raw_data_1/detector_1_events`)

The filewriter must be able to write out event-mode data.

This means the contents of the `NXevent_data` group in `raw_data_1/detector_1_events`

## Questions

- What do we want to do with `event_time_bins`, which aren't meaningful in streaming system?
- Due to an underlying UDP connection from hardware, the streaming system cannot guarantee that frame `N+1` will have a later `reference_time` than frame `N`. Do any consumers make assumptions about this?
* This affects whether we can stream events to file directly, or whether we have to buffer, sort by reference time, and then write to file
- Does mantid have a dependency on event time-of-flights being ordered within a frame? Currently this sort is (optionally) done at `event_aggregator` level as multiple consumers benefit from improved performance with sorted events.

## Potential differences from existing files
- We likely no longer need to apply a random `event_time_offset_shift`, as the new electronics has a much higher time resolution than the old DAE electronics. See https://github.com/ISISComputingGroup/DataStreaming/issues/22 .
- We want to be able to write the veto flags for each frame alongside the event data, to enable downstream consumers to retroactively enable or disable a veto if it chooses:
* `active_vetos`: the veto signals that were actually active for a given frame
* `enabled_vetos`: the vetoes that were _enabled_ in IBEX at the time of data acquisition
* By default downstream consumers will want to mask any events where `active_vetos & enabled_vetos != 0`.
* If adding this logic is problematic for Mantid, we could (optionally) drop the frames at filewriter level instead - at the cost of reducing flexibility and reducing diagnostics we have access to.

Start at the filewriter entry point and compare its existing output with the NXevent_data group under raw_data_1/detector_1_events. Read the event_aggregator behavior and resolve the questions about event_time_bins, reference-time ordering, event ordering, and veto flags. Done means the required streaming event-file format and handling rules are agreed and implemented.

Escrito por el modelo de indexación a partir del texto del issue.