Implement host-only scannables

[dnadlinger]

The fragment design already accommodates scans of parameters where any changes require a new kernel to be launched (for instance, scanning a magnetic field via a closed-loop servo), reflected in the host_setup/device_setup split.

This is not supported in the actual scan implementation yet, though; parameters need a host-only flag, and the scan scheduler/loop need to take it into account.

[hartytp]

Writing up notes from a discussion with @dnadlinger yesterday, I wonder if we should remove host only scannables from the nscan's design goals.

My primary motivation for that is that (as I understand it) supporting host only scannables is the only driver for having different execution models / separate code paths for core / host scans. I see this as having a few downsides compared with having a single portable scan loop which is use for all scans, regardless of whether they are run on the host or coredevice:

• more code to maintain and keep synchronised (when changing the kernel scan loop one has to also remember to change/test the host scan loop)
• having slightly different execution models (host scans aren't chunked, don't deal with fragment exceptions in the same way, call host_setup once per point, rather than once each time the scan loop is entered) makes it harder for users to reason about. My primary use for host_scans has been quickly developing / testing code which I want to run on a kernel at some point. If something odd goes on, I have to think about whether the different execution model could be relevant, which is just more mental burden - even if the differences aren't relevant (they usually aren't), the fact that I have to think about this takes up brain space. This would arguably be, at least partially, mitigated with more documentation around scan loops (so one's not having to diff codepaths to remember what the differences actually are)
• makes the purpose of host_setup and device_setup less clear. e.g. host scans actually call device_setup on the host, which is counter-intuitive (to me at least). Arguably it would be cleaner to have host_setup -> one_time_setup and device_setup -> setup_point (bikeshed names) to reflect the role they play in the scan loop

It's also not obvious to me how useful the kind of use-case pointed to above really is. My experience has generally been that host scans which call into kernels tend to be impractically slow due to multiple compilations. This has tended to push us in the other direction of having the entire experiment be a single kernel and using other techniques to solve these issues.

Anyway, I don't want to overstate any of the above objections - none are killer - but they just feel like points of friction and it's not obvious to me how useful the feature we get in return really is.