HACK: try to use motor.position in dscan
HACK: try to use motor.position in dscan

As originally conceived the D*Plan family assumed that the motors
of interest only had 1 read key, however as implemented in the recent
versions of Ophyd EpicsMotor objects have 2 keys by
default (user_setpoint and user_readback) which causes D*Plan to
fail (due to not knowing which of the keys to use as the 'primary' or
that semantically the those two keys are coupled).

This commit changes the plans to try to use the `Positioner` property
`position` while iterating through the Plan to extract the initial
position that should be returned to at the end of executing the Plan.
This breaks a key abstraction of the Plans (that they only interact with
the objects via the run engine), however this addresses a problem
discovered at the 11th hour without making any major architectural or API
changes to Ophyd or the RunEngine.

The best solution would be to provide an interface to the D*Plan classes
that can take as input the components of the 'motor' devices which
should be scanned, but that would require dropping the SPEC api clone.

ericdill/bluesky,ericdill/bluesky