Rationalize names and behaviour of tutorial devices

[coretl]

There are a couple of classes of devices that we have in tutorials:

1. Simulations where the logic is in the ophyd level, no control system access required
2. Simulations where the logic is in the EPICS or Tango level, requiring control system access

Although the devices we would like to simulate are similar, the implementations are very different, and the requirement of control system access makes me and @callumforrester think we should make the distinction obvious in the naming.

Proposal

We should have the following devices:

• ophyd_async.sim.SimMotor (existing): ophyd level simulation of a motor
• ophyd_async.sim.SimPointDetector and SimPointDetectorChannel (new): N counter channels producing integer count rates proportional to a couple of motors
• ophyd_async.sim.SimFilewritingDetector (was PatternDetector): Gaussian blobs written to HDF with intensity proportional to a couple of motors
• ophyd_async.epics.demo.DemoMotor (was Mover): as SimMotor but with logic in epics database (not an epics simMotor)
• ophyd_async.epics.demo.DemoPointDetector and DemoPointDetectorChannel (was SensorGroup and Sensor): as SimPointDetector but with logic in epics database
• ophyd_async.tango.demo.DemoMotor (was Mover): as SimMotor but with logic in tango server
• ophyd_async.tango.demo.DemoPointDetector and DemoPointDetectorChannel: as SimPointDetector but with logic in tango server
• ophyd_async.fastcs.demo.DemoMotor (was Mover): as SimMotor but with logic in fastcs server
• ophyd_async.fastcs.demo.DemoPointDetector and DemoPointDetectorChannel: as SimPointDetector but with logic in fastcs server

Acceptance Criteria

• Files exist with the right functionality

[callumforrester]

Additional: The original reason we considered renaming demo to sim was to keep inline with ophyd. The devices in ophyd_async.sim have very similar use cases to the objects in ophyd.sim so I feel it's very reasonable to keep them in line. In both cases they are intended for use in:

• Quickstart demos
• Unit tests
• Staging environments

The demo objects for each backend (EPICS, Tango, etc.) are just intended to be examples for the docs, they will rarely ever be instantiated. I think it's actually confusing to imply they are the same as the devices in ophyd.sim.

The expectation for most EPICS devices is that we will unit test them by connecting the intended device to a mock backend and mocking its behaviour using helper functions such as set_mock_value.