Factor out commonalities in builtin ops.

compiler/builtin_ops.m:
    Replace a flat list of clauses, one for each mode of each builtin
    predicate, with a nested set of switches that shows their relationships.

    Specialize the module's interface to the two uses cases the callers
    need: testing to see if a predicate is a builtin, used when setting
    the builtin_status of call goals, and actually generating code, used
    by the various backends.

compiler/hlds_pred.m:
    Switch to using the interface predicate for the first use case.

compiler/bytecode_gen.m:
compiler/call_gen.m:
compiler/erl_call_gen.m:
compiler/ml_call_gen.m:
    Switch to using the interface predicate for the second use case.
Specialize ALL calls to string.format and io.format.

Previously, we specialized calls to string.format and io.format only if
the format string specified no flags, widths, precisions or non-default
bases for any conversion. We now specialize calls to those predicates
regardless of the format string. To make this possible, we now have two
copies of the code to parse format strings.

library/string.parse_runtime.m:
    This new module, carved out out library/string.format.m, contains
    one of those copies. As the name suggests, this copy is used by
    the runtime system.

compiler/parse_string_format.m:
    This new module contains the other copy. As its location suggests,
    this copy is used by the compiler. The separate copy is necessary
    because the compiler's parsing needs are different from the runtime's.

    The main reason for the separation is that the compiler needs to be
    able to handle cases where widths and predicates are given by manifest
    constants, as well as when they are given by the values of variables
    at runtime (when the format string contains conversion specifiers
    such as "%*d"). Having the runtime handle this extra complexity
    would have inevitably increased the runtime's format string interpretation
    overhead, which is undesirable.

    The other reason is that compiler can afford to postprocess the result
    of the parsing in order to avoid having to concatenate two or more
    constant strings at runtime.

library/string.parse_util.m:
    Types and predicates that are common to the library and compiler copies
    of the format string parsing code.

compiler/format_call.m:
    We used to check whether format strings match the supplied list
    of values to be printed by invoking string.format on dummy inputs
    of the supplied types, and seeing whether you got an exception.
    We now call parse_string_format.m instead. Not only does this
    avoid shenanigans with exceptions (which the deep profiler cannot
    yet handle), but it also allows us to specialize all calls
    to string.format and io.format. We therefore do so.

    We used to specialize calls to io.format by creating a single string
    to be printed (using the machinery needed to specialize calls to
    string.format), and then printing that. This did unnecessary memory
    allocations to hold the intermediate strings. We now simply print
    each component one after the other, which avoids this overhead.

library/string.format.m:
    Add versions of the predicates that print chars, strings, ints and floats
    that are specialized to each possible situation about whether the caller
    specifies a width and/or a precision. This means that format_call.m
    doesn't have to generate code that allocates cells on the heap.

    Remove the code that was moved to new submodules of string.m.

compiler/simplify_proc.m:
    List the predicates in string.format.m that the compiler
    may generate calls to in the list of such predicates that we maintain
    to prevent dead_pred_elim from deleting them before format_call.m
    gets a chance to do its work.

compiler/module_imports.m:
    If the code of the module calls a predicate named "format" that
    may refer to string.format or io.format, then implicitly import
    the modules that contain the types and predicates that the code
    generated by format_call.m will refer to. Note that since this
    module_imports.m works on Mercury code that has not been module
    qualified yet, we have to use a conservative approximation.

    Reorganize the way we discover what library modules we have to
    implicitly import. Instead of a separate boolean for each piece
    of functionality that needs an implicit import, put them together
    into a structure. Due to Peter's work on argument packing some
    years back, this is now more efficient as well as more convenient
    that passing around a bunch of booleans. Also switch to passing
    around the structure as an accumulator, instead of having to do
    bool.ors all over the place.

    Since the code for computing the list of modules to be implicitly
    imported can sometimes add a library module to the list twice,
    sort that list and remove any duplicates.

    To make this possible, remove the version of the main predicate
    that appends the implicitly imported module names to a list of
    module names passed by our caller, since we don't want to sort
    THAT list of module names.

    Give the remaining version of that predicate that does this
    a name that better matches the names of related predicates.

compiler/modules.m:
    Conform to the change in module_imports.m. Mark some suspicious code
    with XXXs.

    Remove some redundant comments.

compiler/options.m:
doc/user_guide.texi:
    Add a new option that tells format_call.m what it should do
    when it finds more than one problem with a format string: whether
    it should print a message only for the first problem, or for all
    the problems. (The default is the latter.)

library/MODULES_DOC:
    A list of the all the Mercury source files in the library that
    should be included in the user guide.

library/MODULES_UNDOC:
    A list of the all the Mercury source files in the library that
    should NOT be included in the user guide.

library/library.m:
    Include the new publicly visible new submodule of string.m,
    (string.parse_util). And both string.parse_util and string.parse_runtime
    (which is NOT visible from outside string.m) to the list of modules
    in the Mercury standard library.

    Update the rules for where new library modules should be documented
    to account for non-publically-visible submodules, which we haven't had
    before. Document the need to include new modules in either MODULES_DOC
    or MODULES_UNDOC.

mdbcomp/builtin_modules.m:
    Provide convenient access for format_call.m to the names of the
    submodules of string.m that it needs access to.

library/Mmakefile:
    Add a new target, check_doc_undoc, which checks whether any source files
    are missing from MODULES_DOC or MODULES_UNDOC.

doc/Mmakefile:
    Read the list of modules to be documented from MODULES_DOC. This replaces
    old code that tried to list all the undocumented modules, but missed one:
    it referred to erlang_conf.m instead of erlang_builtin.m.

    When creating the library documentation, filter out any lines that
    contain the string NOTE_TO_IMPLEMENTORS. We now use this mechanism
    to include reminders to implementors in what would otherwise be a
    publically visible part of string.m.

tools/bootcheck:
    Copy MODULES_DOC and MODULES_UNDOC to the stage 2 and 3 library
    directories, since the check_doc_undoc target, which is invoked by
    "make all" in the library directory, needs them.

compiler/hlds_out_module.m:
    When dumping out the table of types, dump out discriminated union types
    in a style that follows our recommended coding style.
Optimize access to poly_infos.

compiler/polymorphism.m:
    Remove a field in poly_infos that wasn't being used. (It contained
    the pred_info.)

    Put the remaining fields into a more logical order.

    Remove unused setter predicates for read-only fields.

    For some setter predicates of the poly_info, the value being written
    is frequently the same as the old value in the written-to field.
    Make these setter predicates not do the update if it is unnecessary.

    Provide a predicate to set the rtti_varmaps at the same time as the
    varset and vartypes, since these are usually updated together, and
    this way we can avoid generating the intermediate poly_info.

    If we know in advance what the name of a new type_info variable should be,
    create it directly with that name; don't created with a different name,
    just to rename it immediately after.

    Give some predicates and variables more meaningful names.

tools/speedtest:
    Add an option, -m (for mix), that executes each under-test version
    of the compiler once before going back to repeat. This minimizes
    the probability that automatic speed throttling of the CPU (due
    e.g. to overheating) will systematically skew the timing results.
    If the executions of the different versions being tested is mixed
    together, any skew from throttling will have effects that are
    mostly random, not systematic.