pj_mkparam() and pj_mkparam_ws() doesn't alter the input string
should therefore be const. This will be useful when making other
changes to the code base later.

torad_coord() of gie.c has this sequence:
```
if( cond )
    axis = l->param + strlen ("axis=");
n = strlen (axis);
```

When the if branch is evaluated, n is always zero
even if on inspection axis is non empty

The reason is that the struct ARG_list which is the
type of l use a variable-length array for the param member

struct ARG_list {
    paralist *next;
    char used;
    char param[1];
};

But this is not a proper way of declaring it, and
gcc 8 has apparently optimizations to detect that l->param + 5
points out of the array, hence it optimizes strlen() to 0.

Reported as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86914

According to https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html,
the proper way of declaring such arrays is to use [0]

In cases such as:

proj=pipeline step proj=utm zone=32 ellps=GRS80 ...

The pj_init code would pick up the ellps information (and other material such as false eastings and northings) from the utm step and place it into the PJ object of the pipeline driver.

This is not the intention, and is eliminated in this PR by terminating parameter searching (done by pj_param) once a step parameter is reached.

* Free format now in cmd lines, in gie, and in init files

* Corrected handling of defaults

* Add demo of integrated definition and validation

* Repair stack-smashing memmove in get_init

* repair paralist corruption, clean up debug output

* Install test files for nmake builds

* Add many improvements following suggestions by @schwehr

* Be consistent in requiring lower case everywhere in gie.c

Also, this Fixes #703 and Fixes #697 

* Replace pj_ell_set with reimplementation supporting ellipsoid inheritance

* remove unreachable code from pj_ell_set.c

* Swap steps, so ellps args are read first, in accordance with historical behaviour

* Add ellipsoid tests to CI targets

* Reduce some optimistic tolerances

OS/X appears to have a slightly off float handling, resulting in differences at the nanometer level. Switching to 10 nm.