BUG/MNT: properly handle string PVs

[tangkong]

Current Behavior

Currently fetching some string PVs returns non-string data

Expected Behavior

If we request a string we should get a string

Context / environment

Playing around with tables and ran into this.

This is something that ophyd also has to deal with, and solves by having the user explicitly request a string. (this is an EPICS problem generally. aioca claims to use the "natural channel data type" if no datatype is specified, but I don't know what this means and it clearly doesn't work

I imagine this is a slightly less common use case for superscore, as string data isn't the first thing you think of as a configuration to restore. But it's something we should support

Steps to Reproduce (for bugs)

1. cl = ControlLayer()
2. cl.get("IM1L0:XTES:MMS:STATE:ERRMSG_RBV")

Suggested Solution

add a string: bool field to Parameter, and also add handling to these fields in our tables.

For aioca specifically we can do: await caget("PV:NAME", datatype=dbr.DBR_CHAR_STR) where dbr is from epicscorelibs. There are a couple different character types that I don't quite understand fully, but we'll have to disambiguate them

[ZLLentz]

The most common case where ophyd/aioca/etc. need help is when we're using an array of integers to mean a string. This is done in EPICS because native string types have fairly small length limits (usually 40 or 60 characters).

Note that these sorts of PVs (CHAR type with element count > 1) are very rarely writeable.

There might also be some user decision needed for enums...

[tangkong]

If you grab the FORMAT_CTRL fields for an enum, aioca (at least) will provide the enum strings. I was using this to infer that a PV is an enum, is this not a reliable source of information?

[ZLLentz]

It should be ok, I was just noting that these are the two cases where the user might want a str representation of their data.