Discuss: Resolve Initial value in setpoints decision

As an developer of IBEX I need to know what the decision is regarding IOC start and set points.

When an IOC starts up the default behaviour for a setpoints is that the pv is 0 with a error of invalid undefined value. This means that they often have an invalid magenta border on them. This is confusing for users so most of our IOCs have not got alarm sensitive borders for set points. There are several other possibilities and this ticket should decide if we are happy with the above or if we should migrate to something else.
The driver for this ticket is that error borders have been added to synoptics so there is lots of magenta on these for set points.

The options are many here are a few:

1. Set points at startup should be set to 0 with invalid undefined alarms. Borders on write PVs should be switched off
1. As 1 but undefined alarm status should be set to No Alarm [see wiki](https://github.com/ISISComputingGroup/ibex_developers_manual/wiki/IOC-Finishing-Touches#12-initialising-setpoints)
1. PVs should have an autosave which sets the value to the last user set value, but does not process the record (i.e. does not send the setpoint)
1. Where easy `@init` should be used to set them from the device
1. Where possible rbv should be copied into the set point field on startup
1. Setpoint should be set to a meaningful value in all cases

We should consider:

1. How obvious it is to the user what is happening on startup and on changes of setpoint from the device between restarts
1. How consistent we can be over our IOCs
1. How hard it is to implement

### Acceptance Criteria

1. A decision is reached as to what the plan for the future is.
1. A plan is made to correct id needed older IOCs

### Notes

We are revisiting decision 2 in https://github.com/ISISComputingGroup/ibex_developers_manual/wiki/Decision-Log but that is probably a good thing.