bug#23926: defcustom with STANDARD=<non-pure-expression> gives confusing results

[Drew Adams]

> whoever uses current-time-string as a defcustom's value tells Emacs that
> the value is not important, because the programmer has no idea when in
> the process of building and restarting Emacs will the value be taken.
> Why does it make sense to rock the boat in this sensitive area for such
> use cases?

Obviously, `(current-time)' was an example, to demo show the problem.

It can sometimes make a lot of sense for a defcustom to use a sexp
that might not return the same result when reevaluated.

The original bug, from which this report is an offshoot, was #4755.
The example there used this defcustom sexp: `(copy-sequence foo)'.

And in the context of the using code there is nothing wrong with
such a sexp: the intention is really to use, as default value, a
(new) list whose elements are the (exact same) elements as those
in the list `foo'.

And yes, this (intentionally) means that the user option, `toto',
that has this value can share the objects that are its initial
elements.  Nothing wrong with using such an initial value for a
user option.

The problem is not with being able to make use of such a sexp for
the default value.  The problem is with how Emacs talks about the
state of the option value.  It miscommunicates to users.  That's
what this bug is about: how Emacs talks about what is going on.