Fix a bug with --detect-libgrades and --make.

compiler/mercury_compile.m:
	Ensure that any extra flags introduced by --detect-libgrades
	get put into mmc --make's option cache.  If this does not
	happen the correct set of library grades will not be passed
	to processes invoked by mmc --make.

	Add --verbose and --very-verbose output to library grade
	detection.
Enable library grade detection by default.

Use -R instead of -r with cp by default.

Fix some documentation errors.

compiler/options.m:
	Enable library grade detection by default.

	Document the --no-detect-libgrades option.

	Make the default install command dir option, -R,
	rather than -r.  The former is more portable.

scripts/Mercury.config.in:
	Do not hardcode the set of library grades at configuration time.

compiler/mercury_compile.m:
	Do not clear the library grade set before adding any detected
	grades since doing so also prevents additional grades being
	specified via the LIBGRADES variable.

doc/user_guide.texi:
	Document --no-detect-libgrades.

	Replace some uses of `:' as a module qualifier.

	Fix a typo: s/outut/output/.
Fix compiler abort during liveness detection.

The compiler would abort during liveness detection on an if-then-else goal
with an unreachable Then branch, due to the Then goal not having its
liveness-related fields initialised.  Bug #51.

compiler/liveness.m:
	    As above.

tests/valid/Mercury.options:
tests/valid/Mmakefile:
tests/valid/bug51.m:
	    Add test case.

NEWS:
	    Announce the change.
Merge branch 'version-13_05-branch'
Disable library grade detection when building Mercury itself.

Library grade detection causes the library installation for the csharp grade
(and probably any grades that use mmc --make) to fail.  (There is likely
a better solution than this, e.g. making --no-mercury-stdlib-dir imply
--no-detect-libgrades, but the handling of command line options in this
part of the compiler is pretty convoluted, so I will look into that
separately.)

browser/MDB_FLAGS.in:
compiler/COMP_FLAGS.in:
deep_profiler/DEEP_FLAGS.in:
library/LIB_FLAGS.in:
mdbcomp/MDBCOMP_FLAGS.in:
mfilterjavac/MFILTERJAVAC_FLAGS.in:
profiler/PROF_FLAGS.in:
slice/SLICE_FLAGS.in:
ssdb/SSDB_FLAGS.in:
	As above.
Check that the compiler supports --no-detect-libgrades.

configure.ac:
	As above.
Fix another problem with --detect-libgrades and --make.

Uses of --no-libgrade and --libgrade in Mercury.options files should override
any detected library grades.  For example, in a directory with a Mercury.options
file that contains

   MCFLAGS = --no-libgrade

we should expect "mmc --output-libgrades" to print nothing.  This was not the case.

compiler/mercury_compile.m:
	Do not combine the detected library grade flags with the ones from
	the command line options.  We need to keep them separate because
	they must be injected into the overall set of command line options
	before any flags from Mercury.options files.

	Add a note about a theoretical problem with DEFAULT_MCFLAGS and
	detected library grades.  It is not a problem in practice because
	the entire point of detected library grades was to avoid passing
	any information about library grades via DEFAULT_MCFLAGS.

	Thread the set of flags from detected grades down to places where
	they are needed.

	If the library grade set is empty, don't print out a single newline
	with --output-libgrades.

compiler/make.m:
compiler/make.program_target.m:
compiler/make.util.m:
	Pass the set of detected grade flags to where they are needed.
Compile time evaluation of string.count_codepoints.

compiler/const_prop.m:
    Do compile time evaluation of count_codepoints where possible.

    Fix an old error in a comment: functions with two arguments are
    binary, not unary.
Disable very verbose messages from library grade detection by default.

compiler/mercury_compile.m;
	Make very verbose messages from library grade detection depend
	upon a compile-time trace flag.  Currently, such messages will
	appear before the usage message if the compiler is invoked
	without any arguments and that looks confusing.
Add ".pregen" or ".spf" to MR_GRADE_OPT variable.

".pregen" and ".spf" are settable on the command-line and should
therefore be included in MR_GRADE_OPT.

runtime/mercury_grade.h:
	As above.
Fix a problem with `--output-link-library-flags'.

When printing the list of link library flags, the Mercury compiler would
attempt to perform any shell escapes required by the current shell**.  This was
causing trouble if one of the libraries involved was libstdc++ and the output
of `--output-link-library-flags' was used in a shell script, for example:

   LIB_LD_FLAGS=`$MMC --library stdc++ --output-library-flags`

This results in LIB_LD_FLAGS containing:

    "-lstdc++" -lmer_std -lmer_rt -lgc  -lm

And Doing something like this,

    $CXX -o foo $OBJS $LIB_LD_FLAGS

would then result in a error, as "-lstdc++" would be treated by the C++
compiler as an argument not an option.  This particular use case is fairly
common when using Mercury stand-alone interfaces.

The solution implemented by this change is to output the link library options
as-is when the compiler is invoked with `--output-link-library-flags' (i.e.  do
not attempt to do any shell escapes).  If, for some reason, the library names
do require shell escapes then doing so is the user's problem.
(There's not much the compiler can do anywayw, since it doesn't know how the
user is going to use the output generated by `--output-library-link-flags'.)

** there's a deeper issue here that the compiler's notion of the
"current shell" is not very good in some spots -- I'm thinking specifically of
the the function quote_arg/1 in compiler/options.m.  Ideally, that function
should use the current setting of `--host-env-type' and not try to guess based
on whether dir.use_windows_paths/0 succeeds or not, however that's a problem
for a separate change.

compiler/compile_target_code.m;
	Do not attempt to insert shell escapes into the link library options
	when invoked with --output-library-link-flags.

	Print a newline after the output from --output-library-link-flags.
Add support for specifying the "system" environment type.

The "system" environment type is the environment type that external programs
invoked by the Mercury compiler (e.g. the C compiler) are run in.  That is, it
is the environment type that you get when you run a command use the C standard
library's system() function.  (Or equivalently, the Mercury standard library
predicate io.call_system/4.)

On sane operating systems this is identical to the host environment type.  On
native Windows**, the system environment is whatever command interpreter the
environment variable COMSPEC is pointing to (by default, cmd.exe), regardless
of what value the Mercury option --host-env-type has.  For example. if
--host-env-type is set to "msys" or "powershell" the system environment is
cmd.exe.  The new option allows us to fully describe to the compiler which
environment types we intend it to interact with.  Not being able to specify
this information has been one of the things preventing the powershell
environment from working properly.

** that is, Windows where the Mercury compiler is a native Windows executable,
so not on Cygwin when compiled against cygwin.dll, but on MinGW/MSYS.

compiler/options.m:
	Add a new option, --system-env-type, which allows the "system"
	environment to be specified.

	Make the --env-type option also set the system environment type
	as well as the host and target environment types.

compiler/handle_options.m:
	Handle the new option.  Make --system-env-type default to the value
	of --host-env-type if the former is not given on the command line.

compiler/compile_target_code.m:
	Use the system env type in place of the host env type in spots where
	the former is what is actually meant.

compiler/globals.m:
	Add a slot to the globals structure to hold the system environment
	type.

doc/user_guide.texi:
	Document the new option.