[m-dev.] --inform-suboptimal-packing and error outputs

[Zoltan Somogyi]

When this option is set, the compiler will generate a message about
types that could be packed more compactly if the order of some
arguments were permuted. (Such as replacing f(bool, int, bool) with
f(int, bool, bool)). The compiler has had this option for a year, but 
it hasn't been useful since argument packing hasn't yet been turned on.
However, knock wood, that should soon change.

With the design I am implementing, which computes the representation
for each type when generating the .int file for the module that defines
that type, the natural (for me, the compiler writer) time to generate
any informational messages about suboptimal packing at the same time.
This is different than the current norm, which is that the vast majority
of error messages are printed when we generate code for the relevant
module. But the work I have been doing on enforcing invariants in the
parse trees of interface files has led to the compiler now being able
to detect and report significantly more problems at interface-file-generation
time than was the case previously.

At the moment, the compiler by default suppresses these extra error
messages, but I don't think that should be the case forever. If a module
has a problem that we can detect when generating its .int3 or its .int file,
the reporting the problem then and there will allow the mmake or mmc --make
invocation to finish quicker, because it won't waste time and CPU resources
to recompile modules dependent on that .int or .int3 file, when those modules
will have to be recompiled *again* once the programmer has fixed the problem.

However, before we can switch to a regime where all problems detected
at interface-file-generation time are reported to the user at that time,
we have to decide where any such messages (whether errors, warnings,
or informational) should go. Should they go to stdout/stderr, as now,
or to module.err, or to a new file such as module.int_err/.int3_err?
None of those seem particularly appealing, though I can think of fewer
negatives for module.err than for the others.

The reason I ask now is that if we want to stay with the current regime
of reporting almost all errors at code generation time, then I have to
reimplement --inform-suboptimal-packing using one set of data structures,
whereas if we plan to eventually switch over to reporting what problems
we can at interface generation time, I have to reimplement it using a
*different* set of data structures. (The current code will need change
either way.)

What do people think?

Zoltan.