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>
tp: Skip tangent check if the previous segment is exact stop
Added an additional check for target velocity of the next segment to fix velocity overrun with slow acceleration machines
Added G61 and G61.1 distinction in TP

Added an additional value for termCond / canonMotionMode to represent
explicit exact stop (vs. exact path). Now, canon and motion pass one of
3 values as terminal condition (exact stop, exact path, or blend), and
the TP handles this accordingly. Exact path is the same behavior as
exact stop, EXCEPT when lines are tangent, in which case it does not
stop.
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
Merge branch 'hotfix/g61-exactstop'
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