French doc update and cleaning

Signed-off-by: Francis Tisserant <tissf@free.fr>
French doc update: Document G5,G5.1,G5.2,G5.3 NURBS/spline commands

Signed-off-by: Francis Tisserant <tissf@free.fr>
interp: print correct filename in message

The fopen arguent was changed, but the ERS argument
was not.
interp: need to initialize context_struct

While tracking down the intermittent failure in
tests/interp/subroutine-return/, I ran task under
valgrind and saw that the problem occurred routinely,
and seemed to be associated with this valgrind
diagnostic:

Conditional jump or move depends on uninitialised value(s)
   Interp::unwind_call(int, char const*, int, char const*) (rs274ngc_pre.cc:1565)
   Interp::execute(char const*) (rs274ngc_pre.cc:511)
   emcTaskPlanExecute(char const*) (emctask.cc:565)
   readahead_reading() (emctaskmain.cc:593)
   main (emctaskmain.cc:1179)
 Uninitialised value was created by a heap allocation
   operator new(unsigned long) (vg_replace_malloc.c:287)
   emcTaskPlanInit() (emctask.cc:421)
   main (emctaskmain.cc:3002)

After arranging to properly construct a "context_struct", the valgrind
diagnostic and the test failure both went away.
Merge remote-tracking branch 'origin/v2.5_branch' into 2.6

Conflicts:
	docs/src/config/ini_config_fr.txt
	docs/src/gcode/gcode_fr.txt
Docs: fix float value with old data

Signed-off-by: John Thornton <jthornton@gnipsel.com>
Docs: try to word synopsis to be a bit clearer in the description

Signed-off-by: John Thornton <jthornton@gnipsel.com>
gmoccapy_1_1_5_4 - solved screen 2 bug

After the user selected to show screen 2 on the settings page,
gmoccapy started with an error, because screen2 was activated
to early.
gmoccapy_1_1_5_4 - fixed screen 2 error

ver. 1.1.5.4
- solved a bug showing screen2 at start up. Screen2 was initialized to early
  resulting in a runtime error
pncconf -fix an icompatibility between MESA XMLs and linuxcnc XMLs

Linuxcnc used '???' to designate no secondary function, just GPIO,
where MESA use 'not used'. now both work
This made some GPIO pind not show in pncconf
Merge branch 'v2.5_branch' into 2.6
sim: Fix 32-bit truncation of rdtsc on x86_64

.. this problem was exposed when using hal_parport in resetting mode
in uspace on amd64.
docs: Fix cut&paste errors

.. somebody forgot to fully customize their skeleton.
task: silence a warning with gcc 4.8 + boost 1.55.0

This bug with certain boost functions is known upstream
https://svn.boost.org/trac/boost/ticket/8546
but is not fixed in the version of boost packaged for debian testing
(1.55.0.2)
task: safely format these messages

.. rather than just silencing a correct warning.
gmoccapy_1_1_5_5 - solved tool change with remap and tooledit widget

ver. 1.1.5.5
- if using remap, an error has been launched, if the user used
  the buttons of the tool edit widget to change the tools
  (not posible to change to auto mode)
  I moved the resting procedure of self.tool_change to
  hal_status_intp_idle to solve the wrong behavior
gmoccapy_1_1_5_5 - solved bug using change remap and tool edit widget

ver. 1.1.5.5
- if using remap, an error has been launched, if the user used
  the buttons of the tool edit widget to change the tools
  (not posible to change to auto mode)
  I moved the resting procedure of self.tool_change to
  hal_status_intp_idle to solve the wrong behavior
gmoccapy_1_1_5_6 - new hal pin for program progress

ver. 1.1.5.6
- introduced three new hal-pin to signal program progress info
  gmoccapy.program.length = S32, OUT
  (total number of program lines)
  gmoccapy.program.current-line =S32, OUT
  (current executed line)
  gmoccapy.program.progress = FLOAT, OUT
  (progress in %)

  This pin do not work very perfect when using subroutines
  or remap procedures
gmoccapy_1_1_5_6 - new hal pin for program progress

ver. 1.1.5.6
- introduced three new hal-pin to signal program progress info
  gmoccapy.program.length = S32, OUT
  (total number of program lines)
  gmoccapy.program.current-line =S32, OUT
  (current executed line)
  gmoccapy.program.progress = FLOAT, OUT
  (progress in %)

  This pin do not work very perfect when using subroutines
  or remap procedures
hostmot2: fix 'set but unused' compiler diagnostics

In these cases, 'r' was intended to be used to hold the negative
errno value in the case of a failure.  Ensure that r starts with a
negative errno value (Arbitrarily, -EINVAL) and propagate it back to the
caller.

In some cases, this means an already detected failure will actually
be propagated up to the caller.  For instance, hm2_bspi_parse_md would
return success even when it failed to allocate memory.

In a few cases, a return of -1 was also changed to -EINVAL, in order to
obey the usual 'return value is negative errno value' idiom.