Compatibility option for local PVs

[kasemir]

Local PVs loc://... used to have a value of 0 unless they were specifically initialized to a certain value.
Now they start out as null, unless initialized or until a first value is written.
That may be 'correct' in the long run, but breaks existing displays which don't expect null.

A new preference setting 'init as zero’ would restore the old behavior and allow a better transition:
Newly created PVs will have value 0 (zero, instead of null) to allow existing displays to run.
There will be a logged warning “PV ‘loc://xyz’ not initialized” to allow display maintainers to spot such old displays and update them.

[kasemir]

The old behavior also allowed multiple initialization values like "loc://x(4)", "loc://x(5)".
Depending on which one was used first, the initial value of the PV would be 4 or 5. The "other" initial value was ignored as soon as the PV already had an initial value.
The initial value was reproducible, but not always predictable.

The new behavior is to fail when detecting conflicting initializers.

Again, in the long run the new behavior is 'correct'.
Is this a minor issue for existing displays, we can live with it, or must the compatibility option also support the old behavior?

[shroffk]

Moving to milestone 3.2.10

[gcarcassi]

Moving to 3.2.11
No time to work on this.