Support the new device-independent PCO records for generating triggers

[MarkRivers]

The existing code in tomoscan_pso.py talks directly to the Ensemble and A3200 controllers for configuring the PSO trigger outputs from the rotation stage. This is not a clean solution, and does not work for other controllers, including the Aerotech Automation1, which requires function calls rather than strings.

I have extended the Model 3 API in the motor module to support position compare output (PCO) in a device-independent way. The generic records are PCOStartPosition, PCOEndPosition, PCOIncrement, and PCOPulseWidth. Some controllers support additional records for advanced features. This new API is currently implemented for:

• Aerotech Automation1
• Newport XPS
• Galil DMC-41x3

This PR adds support for these PCO records in tomoscan.py and tomoscan_pso.py.

It also adds support for the APS 6-BM-B station, which uses this support for an Aerotech Automation1 controller.

• tomoscan/tomoscan-6bmb.py
• tomoscan/iocBoot/iocTomoScan_6BMB

[MarkRivers]

It would be nice to implement the PCO records for the Aerotech Ensemble and A3200 controllers. Unfortunately this is non-trivial because these drivers are Model 2 drivers (asyn interfaces in C) rather than Model 3 drivers (C++ classes derived from asynMotorController and asynMotorAxis).

I think Claude could probably do a good job converting these from Model 2 to Model 3, since it is pretty straightforward. Once they are Model 3 then adding support for the PCO functions should be pretty easy.

[decarlof]

Ran git merge-tree against current master and against my fork's master (decarlof/tomoscan (https://github.com/decarlof/tomoscan)) — no conflicts either way.

The gating pattern is consistent and backward-compatible: every new PCO code path is wrapped in if pso_model == 'EPICS PCO':, and the existing Ensemble / A3200 paths are unchanged. New PVs in tomoscan.py are only added if 'PCO' is in pv_prefixes, so nothing changes for beamlines that don't opt in.

BTW, I plan to open a PR shortly from decarlof/master to bring my downstream changes back upstream — mostly additions (new beamline configs, small fixes), no changes to the base class. Best to merge that in soon so our forks don't diverge.

ok to merge from my side

[decarlof]

@MarkRivers shall I merge?