Curv has an optional user-defined configuration file, which the `curv`
command reads during startup.

The configuration file provides default values for -O options which are
given on the command line.

Loading the Config File
-----------------------
$XDG_CONFIG_HOME defines the base directory relative to which the Curv
config file is stored. If $XDG_CONFIG_HOME is either not set or empty,
it defaults to "$HOME/.config", unless $HOME is either not set or empty,
in which case there is no Curv config file.

There are two possible names for the Curv user configuration file.
First, we try "$XDG_CONFIG_HOME/curv.curv".
If this file exists, we evaluate it as a Curv syntax source file,
and the result must be a record value.
Otherwise, if the directory $XDG_CONFIG_HOME/curv exists, we evaluate it
using directory syntax.

Update: At present, I just import $XDG_CONFIG_HOME/curv using either file
syntax or directory syntax.

Accessing Configuration
-----------------------
In libcurv, Curv configuration is stored in System::config_,
as a value of type Shared<const Record>. Not implemented yet; don't need it.
So far config is only used to provide defaults for export parameters in the
Curv program, and libcurv knows nothing about this.

Idea: `config` is a builtin binding.
It sounds cool, but why do I need it? What are the use cases?
Curv is a file format for sharing geometric models, and it's not obviously
good for shared models to depend on config. So I've leave this feature out
until required.

The Config Namespace
--------------------
Here's the current CLI -O configuration:
  mesh (STL, OBJ, X3D)
    vsize, jit, adaptive,
  mesh (X3D)
    colour
  viewer, GPU (aka Frag options)
    aa, taa, fdur, bg
  PNG
    xsize, ysize, fstart, animate, + the Frag options

I could just put all these names at the top level of the config record.

However, I might want different Frag options for PNG export vs the Viewer
(eg, high quality for PNG export, higher performance for the Viewer).
So then I need a 2-level namespace, eg like:
  config
    mesh
      vsize, jit, adaptive, colour
    view
      aa, taa, fdur, bg
    image
      xsize, ysize, fstart, animate, + the Frag options
I like this one better:
  config
    export
    viewer
    repl

Command Line Overrides
----------------------
All of the -O options can be given default values in the config file.
Which means all -O option values are Curv values.
What about '-O colour=face|vertex' for -o x3d?
'face' and 'vertex' need to either be strings, or symbols.
See <language/Symbols> proposal.
Depending on the outcome of this proposal, we will use one of the following:
    -O colour='"vertex"'   -- in bash
    -O "colour=""vertex""" -- in cmd.exe, but for caveats see (*)
    -O colour=#vertex
(*) https://stackoverflow.com/questions/562038/escaping-double-quotes-in-batch-script

All configuration can be overidden on the command line.
Currently, all of the relevant command line options are -O options.

Algorithm for parsing configuration and -O options.
* error checking: I want to report invalid -O options, and invalid config
  settings.
* For each internal options structure, like io::Frag_Export, there is a
  Parse_Opt function that validates a specific name/value pair,
  modelled after parse_frag_opt(). This validates a name/value pair from
  either the config, or from a -O option.
* template<T> typedef bool (*Parse_Opt)(

Let's say there is a flat config namespace, and we ignore names not relevant
to the current export context.
 1. An option structure like Frag_Export is default initialized.
 2. config values with matching names are copied into the option struct,
    unknown names are ignored. curv::Values are converted to the correct type.
 3. All of the -O options are processed. Bad names are reported as an error.
    Strings are evaluated as Curv values, then converted to the correct type.
What API do we use?

I could extend the Export_Param::Map to contain a string field (for the -O
value) and a Value field (for the config value). Load the config record into
the Export_Param::Map. Then, the current API is mostly unaffected and only
the internal implementation of Export_Params needs to change.

A Map item now contains a string `opt` and an Value `config`, both nullable.
How do we evaluate it?
* Currently we build a Param_Prog pp(*this, p), then we use pp.eval()
  and At_Program(pp) as an error context.
* If the parameter has no opt string, only a config value, then we still
  need a Context for reporting a type or range error on the config value.
* The minimum config context is the pathname of the root config file and
  the data path of the config field.
* Alternatively, we need the 'Program' for the config source file.
  The important part is the Location. But, what if the config file
  is a directory tree containing multiple *.curv files?
  The config value containing the error could come from multiple sources.
  Tracking this is tricky. In theory, this information can be reconstructed
  from the minimum config context.

At_Param cx(*this, p);
cx.eval(deflval)

Lighting Models
---------------
There is a default lighting model, which has two attributes, background_colour
and contrast. The user can override either or both of these attributes,
and can also replace the default lighting model with another,
perhaps user-defined lighting model.

Perhaps user-defined lighting models can provide additional parameters that
can be selectively overridden using the config file or the command line.

In 3D, these config variables are called
    viewer.lighting
    viewer.lighting.background_colour
    viewer.lighting.contrast

In 2D, there is still a background colour, but there is no lighting model.
What is it called? Currently it is called -Obg=.