* Refactored tpRunCycle, tpAddLine, tpAddCircle, and tpAddRigidTap
* Cleaned up const specifiers for many function pointers
* Implemented pass-by-constant pointer for a few large inputs
* Reformatted documentation to be Doxygen compatible

Demonstrates const pointer passing instead of pass-by-value to a few
posemath functions that are used in the trajectory planner.

* Fixed a few more structs passed by value
* Formatting fixes

…stant data

…alue

An alternative to PmLine was added in PmCartLine, which strips out all
of the rotation information. Because each axis is treated as orthogonal
and linear as far as trajectory planning, there is no use for an
additional rotation term. More complex kinematics are dealt with
external to TP, so there is no need for the extra space and processing.

This implementation is basically a copy/paste from the octave
scratchwork.

Need to track down init error in Circle init function.

The output looks nominally correct for a simple test case.

* Fixed issue where theta was half of what it should be, causing arcs to be too short.
* Fixed intersection angle bug due to comparing prev_tc to itself.
* Fixed backward walk to be limited in depth. Hard-coded a constant for now, but eventually this should be user-controllable.
* Fixed debug output redundant definitions

Tested with square-spiral test code.

A few functions looked like:

int myfunc(var1,var2){
    ...
}

Reformatted to look like this:

int myfunc(var1,var2) {
    ...
}

Added Sam's test ini and code and reproduced the feed override bug.
Apparently, the feed override was being reset at the emcStatus level,
for no obvious reason. This lead to an overhaul of how feedrate is
handled in tp to isolate this issue.

Faster update frequency does improve blend performance as expected,
since the effective sampling rate of the trajectory is increased.
Unfortunately, this configuration has uncovered another issue. There is
a divide-by-zero happening rarely, but the random walk G-code reveals
it. It's likely due to very small line segments being created during
some of the blends.

TODO: add a check to the arc blend that bounds the blend arc size based
on requested velocity, acceleration, length, and cycle time.

As suggested by Michael, the static variables holding spindle position
info were rolled into a single struct, within the TP_STRUCT itself.
There are a few more stray globals here and there, but now tp.c is
acting a bit more like a class. Most functions prefixed with "tp" pass
the TP_STRUCT as the first argument, which is class-like.

TODO:
* Move syncdio into TP_STRUCT
* add const specifiers to remaining TP functions
* pick a style concerning arguments in terms of input / output order
* Docstrings moved to headers?

tpAddLine, tpAddCircle, and tpAddRigidTap were reverted to pass the
input data by value. This is mostly to keep the pointer passing within
tp.c, so that we don't have to go digging through multiple files to
figure out where the memory is originally allocated.

To help diagnose issues with small segments, new debug data was added to
tpCreateBlendArc. This is useful to track down exactly which segments
were being shrunk too much. Short segments are causing issues with
overshoot, since a very short segment can be skipped entirely if the
velocity is too high.

Added a candidate check for blend arcs to make sure that we don't
shrink the previous segment too much. If we can't entirely eliminate
the previous segment, then it's better to shrink the blend arc so that
the line segment is long enough for TP to land on at least once.

Works with simple rapid test, because we're not falling back to
parabolic blends. Something is still wrong with the refactored parabolic
blends, though. Next step is to force a failure every time. We should be
able to fall back, but currently that may not be working.

One problem with having multiple types of blending is each method has
its own limits on acceleration, in addition to a trajectory segment's
maxaccel. For example, parabolic blends scale acceleration down by 0.5
so that two segments can overlap without exceeding the max accel in any
direction. These limits are not necessarily there for other cases, so
this commit stores the scale factor separately.

Parabolic blending was crashing out due to an improper estimate of being
on the final deceleration. The final decel calculation assumed that we
were on the final deceleration if the ideal new velocity was close to
what we could actually reach based on machine limits. This should only
be true when we are decelerating to a stop.
TODO: what exactly changed that made this assumption not work anymore?

One issue that has plagued these changes is that parabolic blend code
was spread out over tpRunCycle. Now a lot of the parabolic blend stuff
is packed into a few functions, shrinking tpRunCycle.

Removed optimization bug that was causing large overshoots and
some acceleration spikes.

Remaining issues:
* infinity norm is used to calculate limiting acceleration for a given TC.
  The trajectory planner needs to know machine limits if it is to
  compensate.
* Occasional segfault appears on load after a clean shutdown. No issues
  while running so far.

It may be useful to have element-wise multiplication for PmCartesians.
The name isn't the best choice, but it follows the convention.

Added a simple check to bound blend arc acceleration to the lowest
linear axis acceleration. This is a temporary fix, since we need to
enable STRUCTS_IN_SHMEM for this to work.

…aggressive

Check that prev_tc's final velocity is reachable from the previous and
current segments, so that we never ask for a velocity higher than we can
reach at any time.

Also, bound the segment velocity in the optimizer itself to ensure that
we don't overshoot too much.

Unfortunately, the optimizer and arc blend planner have grown somewhat
organically over the past few weeks, and will need a design review soon.

…c test

Velocity smoothing introduced a bug in optimization, where the peak
velocity of the last segment on the queue changes when a new tangent
move is added. The original algorithm trusts that these velocities are
constant, so it overestimated how fast the previous segment could go,
causing acceleration violations.

The simple fix is just to start 1 deeper in the queue. Effectively, the
last move on the queue is in "exact stop" mode until a new move is
added.

The price of velocity smoothing is that it caps the velocity of the
previous and next segments. Adding a minimum blend ratio skips smoothing
for segments where the arc is short compared to the lines. This lets the
line segments accelerate to the full requested velocity, rather than
being capped at the arc's velocity.

…rshoot

…answer. it also has the nasty side-effect of not quite stopping at the end of the straight segment test.

…nothing at all on the arc test

…vershoot

Due to velocity smoothing, sometimes blend arcs with rapid traverse
segments will slow the feed rate dramatically, causing a long traverse
segment not to exceed the speed of the arc. This tweak mostly fixes this
issue by disabling the velocity cap for small blends.

Partially addresses issues seen during wait-on-spindle moves. if the
trajectory component was changed to a stop condition, the final velocity
was used anyway. Now, any non-tangent behavior returns a 0 final
velocity. There may be edge cases here still, and this really suggests a
bit of a rethink of this structure. The band-aids are getting deep...

DoTangentBlend was not properly updating emcMotStatus, except during an
overshoot. When single-stepping was enabled, nexttc was set to NULL,
which terminated DoTangentBlend early, so the status was never updated.
This also fixes the GUI update issue.

…auses havoc on accel

…s overly conservative

* broke out linuxcnc_control into its own file
* debugged the test script so that it actually auto-starts LCNC now
* made a profiling script to almost completely automate a test run