[m-rev.] for post-commit review: require errorN functors to contain at least one error

[Zoltan Somogyi]

This diff encodes in the type a desirable invariant.
For review by anyone.

The diff is huge and mostly boring, so most of it can be ignored.
I am seeking feedback mostly on the following topics.

- In a few places, such as mercury_compile_args.m, there is
  a nontrivial change in the logic of the code. Another set of eyes
  to check these could help.

- In a few places, we do return errorN functors wrapped around
  an empty list of error_specs. The new code handles this using
  the new maybe_errorNel types, but people who know the code
  where these new types are used may be able to avoid the use
  of empty lists of error_specs in these situations.

- And two asthetic questions. Can anyone think of a better way
  to indicate that an empty list of errors is a possibility than the
  "el" suffix used by this diff? And should the okN and errorN
  function symbols of these types also have an "el" suffix, or
  whatever the marking ends up being?

Zoltan.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Log.me
Type: text/x-troff-me
Size: 3663 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20260709/cbcc9f22/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DIFF.me.gz
Type: application/gzip
Size: 50157 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20260709/cbcc9f22/attachment-0001.gz>