bug#66912: With `require', the byte compiler reports the wrong file for errors.

[Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

> year, in place of the current error output 
>
>     test-byte-compile-errors.el:2:11: Error: Wrong type argument: listp, baz
>
> the following line would appear:
>
>     test-byte-compile-errors.el:2:11: While loading "test-byte-compile-errors-2.el" Error: Wrong type argument: listp, baz

I can definitely live with this syntax, but maybe we should use
something more like what GCC uses (e.g. for errors in #included files)
which puts the "While loading" info on separate lines.

> This could surely be achieved with something like the following in Fload:
>
>     (handler-bind ((lambda (err)
>                     (signal (car err)
> 		            (combine-error-info "While loading " file
> 			                         (cdr err)))))
> 		  readevalloop (Qget_file_char, &input, hist_file_name,
> 		      0, Qnil, Qnil, Qnil, Qnil);)

That was my thinking as well (tho see below).

> (where, obviously, the details need to be worked out).  It would need
> augmenting with handling for (eq debug-on-error t), and probably a few
> other things, too.

`combine-error-info` is a bit problematic because we don't have clear
rules about the content of (cdr err), other than the fact that it should
be a list (tho we don't even enforce that very much).
Most likely we could append elements to that list, but we'd have to
worry about interactions with other libraries wanting to do similar
things.

So I was thinking that we should go instead with:

   (handler-bind ((error (lambda (err)
                           (push file (gethash err our-table-of-error-source)))))
     	  readevalloop (Qget_file_char, &input, hist_file_name,
     	      0, Qnil, Qnil, Qnil, Qnil);)

Where `our-table-of-error-source` would be a weak eq-hashtable.
Emacs Lisp guarantees that the `err` we get here will be the exact same
object that any subsequent `condition-case` will get when it finally
handles the error so that it can use `gethash` to fetch our
side information.

Note that we don't `signal` the error again, instead we let the error
handling code propagate it further, which is what `handler-bind` does
when the handler returns normally (which should also eliminate the
possible problems of interaction with `debug-on-error`).


        Stefan