move auto colouring decision

...from the `Set_config_defaults` function, to being done directly
in `build.sh` (the component which is also responsible for loading
functions, loaded at the start of every script, including the front
end).

thus the colouring decision will now correctly...
 - apply to the frontend, such as to the 'root privileges needed'
   error, the 'no such script' error, and the command name
   colouring that I want to add (the most significant issue).
 - apply to error messages generated by the `Arguments` and
   `Read_conffiles` functions, which are called before
   `Set_config_defaults` by scripts.

as things were, due to the comparison with "false", colour would
_always_ be used in these places (unless _COLOR_ERR=false or
_COLOR_OUT=false wrt. the new command highlight, were set in the
environment when executing a script throught the frontend).

this would not be a problem for normal terminal use of course,
besides being inconsistent where color were turned off, but would
be a bit of a problem if redirected to a file.

a re-evaluation of _COLOR is performed in `Set_config_defaults` to
adjust _COLOR_OUT and _COLOR_ERR where necessary, to correctly
respond to _COLOR being set in saved config files (disabled by
default but a user could always enable), after the point of config
files being loaded.

_COLOR can still be controlled from the environment just as before,
overriding both _COLOR_OUT and _COLOR_ERR.

note that this does not address the fact that --color|--no-color
do not work in the frontend and thus will not impact the colouring
of to-be-introduced command highlighting. this needs to be
addressed separately.

Gbp-Dch: Short

0 files changed, 0 insertions, 0 deletions