Include pmac trigger logic as visr device

[gkalua]

Instructions to reviewer on how to test:

1. Updates the visr detectors suffices
2. Includes Pmac Trigger Logic as a device for Visr.

Checks for reviewer

• Would the PR title make sense to a scientist on a set of release notes
• If a new device has been added does it follow the standards
• If changing the API for a pre-existing device, ensure that any beamlines using this device have updated their Bluesky plans accordingly
• Have the connection tests for the relevant beamline(s) been run via dodal connect ${BEAMLINE}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.08%. Comparing base (8dfcdaa) to head (ebd5690).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1952   +/-   ##
=======================================
  Coverage   99.08%   99.08%           
=======================================
  Files         314      314           
  Lines       11804    11807    +3     
=======================================
+ Hits        11696    11699    +3     
  Misses        108      108           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[shihab-dls]

Looks good. Just one suggestion for the docstring, feel free to merge in after addressing.

[abbiemery]

Why do we want a trigger logic as a device? It looks like I have missed a lot of context here with the changes to ophyd-async and what constitutes a TriggerLogic. What I knew as TriggerLogic, which contained the required state and logic to prepare a detector, appears to now be a DetectorTriggerLogic. This being set up via plans/stubs to set detectors up how we want.

Seeing a PmacTrajectoryTriggerLogic as a flyable device in its own right felt initially odd but this is going to be down to the fact i've not been involved in this project for a long while. Feel free to point me to an ADR on these changes or anything pmac related, or we can have a chat about how this works, as I would be interested to know. However, since I don't understand why this might be needed, I'm no help for reviewing.

[gkalua]

Currently, PmacTrajectoryTriggerLogic must be registered as a beamline device in dodal rather than instantiated inside a plan.

It is an ophyd-async Device that takes ownership of PmacIO as a child. Constructing it ad-hoc inside a plan means a new instance is created on every call; on back-to-back fly scans this raises 'Cannot set the parent of PmacIO to be PmacTrajectoryTriggerLogic because it is already PmacTrajectoryTriggerLogic', since ophyd-async does not permit a device to be re-parented.

Note: the current ownership model (PmacTrajectoryTriggerLogic owning PmacIO) is a workaround and will be revised in bluesky/ophyd-async#1220

[coretl]

I suggest you add the Pmac as a Reference to the (temporarily badly named) Logic class to opt out of the parent-child relationship so it doesn't need to be added to dodal:
https://github.com/bluesky/ophyd-async/blob/dfc2fccff9c045fdf7565dfe206ea34655738d22/src/ophyd_async/core/_utils.py#L372-L378