Integrate fields from the yaq client

[ksunden]

Closes #66

This is an initial implementation, there are some things including about the underlying implementation of fields in yaq that I have questions about smoothing out after working on this.

• Currently have to reach into the private variable _protocol of the client

• Clunky access of fields with confusing "fields" entry in the record type which is an avro thing, not the yaq field.

• Do we need the _read method, if so, do we need a parallel method for configuration?

• We do not currently have any fields defined in yaq that are dynamic=False, thus I have not tested the configuration code really at all. Further this makes me consider if dynamic is even doing what we want it to at all.

has-limits

• Currently kind of works, but I suspect would cause problems downstream
• Does not define shape at describe time
• We probably do not wish to expand ndim just for limits on each hardware...
• We probably do not care to actually record it at every point, should there be a way to declare not to do so: kind?
• should limits just be left out entirely, if so should it not be a field or should it be special cased by calling del in _has_limits.py

has-position

• Currently "double" define the position and destination as "name_position/name_readback" and "name_destination/name_setpoint"
• I wish to assert that "name_readback" is not the norm in the bluesky community as far as I can tell, and in fact the position should just simply be "name"

general comments

• Do we care about order? I know I do some order dependent things in our plans to determine the units (I take the units from the first entry in describe... perhaps we could prefer whatever the standard readback key is from previous discussion point
• Current order is all of the fields first in alphabetical order (because yaq-traits alphabatizes it, not anything we do here), followed by those defined by traits, which could potentially be removed based off of conclusions from previous discussion points.

[ksunden]

Created as a draft as implementing has served to raise a lot of questions that I would like to reach more of a consensus on before fully finishing this feature.

In other news, I'm pretty confident on the path forward to addressing #67 after working on this and doing a bit of additional looking at bluesky/ophyd internals.

[ksunden]

Test failures are because we are inconsistent in the ecosystem on how we actually define fields... so I think we need to address that before we merge this feature that depends on the field definitions... (also needed to make development of yaqc-qtpy sane)

[ksunden]

Tests pass locally, but rely on new behavior in as yet unreleased yaqc... we will have to pin upon release of yaqc