bug#41680: Recent compiled byte code changes broke loading

[Daniel Colascione]

f0b0105d913a94c66f230874c9269b19dbbc83bd changes how we generate and
evaluate byte-code objects. It causes a weird wrong-type-argument when
loading some elc files, however:

Debugger entered--Lisp error: (wrong-type-argument stringp
("/home/dancol/emacs/conf/gnus.elc" . 1556))
  read(get-file-char)
  load("~/emacs/conf/gnus" nil t)
  (lambda nil (load "~/emacs/conf/gnus" nil t))()
  eval-after-load-helper("/home/dancol/edev/debug/lisp/gnus/gnus.elc")
  run-hook-with-args(eval-after-load-helper
"/home/dancol/edev/debug/lisp/gnus/gnus.elc")
  do-after-load-evaluation("/home/dancol/edev/debug/lisp/gnus/gnus.elc")

I did a bit of debugging. We're passing some kind of cons cell to the
Fstring_as_unibyte call in read1. (The CDR seems invalid too somehow?)

There's a difference in the generated elc file ("gnus.elc" above) that
seems to drive the error.

Bad: (defalias 'qtmstr-setup-summary-mode #[nil #@38 ("\300\301!\207" .
[hl-line-mode 1])(#$ . 1556) nil 2])

Good: (defalias 'qtmstr-setup-summary-mode #[nil "\300\301!\207"
[hl-line-mode 1] 2])

Reverting f0b0105d913a94c66f230874c9269b19dbbc83bd seems to fix the
problem for now.