Fix for stale or soon to be stale RBV values during motor record initialization

[kmpeters]

This pull request contains the proposed changes to devMotorAsyn.c from issue #164

[MarkRivers]

This code makes calls like the following in init_controller.

 pPvt->pasynFloat64->write(pPvt->asynFloat64Pvt, pasynUser, (double)(pmr->mres/pmr->eres));

That is not allowed because you are directly calling the driver without any locking. Multiple records could be calling the driver at the same time.

I believe the correct way to do this is to use the asynFloat64SyncIO interface. As an example look at this line in devAsynFloat64.c::initAo().
https://github.com/epics-modules/asyn/blob/8573487454c20f6698f144ac68eb51ae68a22450/asyn/devEpics/devAsynFloat64.c#L640

[motorapp]

Thanks Mark for providing the example, very helpful. I agree with the request to change to use asynFloat64SyncIO instead. I've provided an updated devAsynMotor.c in case it reduces work loads.
devMotorAsyn.tar.gz

[tboegi]

I took the freedom to extract the code from devMotorAsyn.tar.gz and transform it into a PR:
#167

The change for MOTOR_RESOULTION is not part of this PR (that should go into
a different commit anyway)

[kmpeters]

I took the freedom to extract the code from devMotorAsyn.tar.gz and transform it into a PR: #167

This pull request is also an attempt at that. I haven't had time to make and test the change @MarkRivers suggested.

[tboegi]

@kmpeters
I didn't want to confuse you.
#167 should contain a cleaned up version of devMotorAsyn.c
Feel free to have a look (and use it in this PR or not)

[kmpeters]

Merged #167 instead of this pull req.