bug#9712: 24.0.50; doc about byte-compiling `defcustom'

[Drew Adams]

If, as the comment in the code suggests, the aim in commenting out the code
(that would otherwise let the byte-compiler eval the defcustom value and assign
the result as a constant in the compiled code) is to avoid having users see the
byte-compiled value in Customize buffers, then why not solve both problems
instead of choosing one or the other?

Byte-compiling should, as is everywhere claimed (e.g., the doc), replace the
VALUE with its evaluation, as a constant, in the byte-compiled code.  But
nothing prevents saving the Lisp sexp that evaluates to that constant.  And
nothing then prevents making that saved sexp available to the user in Customize.
We could even let the user see both: the value and the sexp that eval'd to it.

And most evaluation of a defcustom value leads to a normal Lisp object that
users are used to seeing anyway (string, number,...).

Was there some other reason, besides not having the user see the sexp's value,
for not letting the byte-compiler treat the defcustom VALUE normally?