Refactoring and lots of bug fixes. Updated homing cycle.

WARNING: There are still some bugs to be worked out. Please use caution
if you test this firmware.

- Feed holds work much better, but there are still some failure
conditions that need to be worked out. This is the being worked on
currently and a fix is planned to be pushed next.

- Homing cycle refactoring: Slight adjustment of the homing cycle to
allow for limit pins to be shared by different axes, as long as the
shared limit pins are not homed on the same cycle. Also, removed the
LOCATE_CYCLE portion of the homing cycle configuration. It was
redundant.

- Limit pin sharing: (See above). To clear up one or two limit pins for
other IO, limit pins can now be shared. For example, the Z-limit can be
shared with either X or Y limit pins, because it’s on a separate homing
cycle. Hard limit will still work exactly as before.

- Spindle pin output fixed. The pins weren’t getting initialized
correctly.

- Fixed a cycle issue where streaming was working almost like a single
block mode. This was caused by a problem with the spindle_run() and
coolant_run() commands and issuing an unintended planner buffer sync.

- Refactored the cycle_start, feed_hold, and other runtime routines
into the runtime command module, where they should be handled here
only. These were redundant.

- Moved some function calls around into more appropriate source code
modules.

- Fixed the reporting of spindle state.
Homing and feed hold bug fixes.

WARNING: Bugs may still exist. This branch is a work in progress and
will be pushed to the edge branch when at beta stability. Use at your
own risk.

- Homing freezing issue fixed. Had to do with the cycle stop flag being
set incorrectly after the homing cycles and before the pull-off
maneuver. Now resets the stepper motors before this can happen.

- Fixed an issue with a rare feed hold failure. Had to do with feed
hold ending exactly at the end of a block. The runtime protocol now
sets the QUEUED and IDLE states appropriately when this occurs. Still
need to clean this code up however, as it’s patched rather than written
well.

- Updated version build via $I command.

- Forgot to comment on a new feature for the last commit. Since steps
are integers and millimeters traveled are floats, the old step segment
generator ignored the step fraction differences in generating the
segment velocities. Didn’t see like it would be much of a big deal, but
there were instances that this would be a problem, especially for very
slow feed rates. The stepper algorithm now micro-adjusts the segment
velocities based on the step fractions not executed from the previous
segment. This ensures that Grbl generates the velocity profiles EXACTLY
and noticeably improves overall acceleration performance.
Merge commit 'cd71a90ce8a770e0030ed6c9bac805b89724e275' into dev

Conflicts:
	limits.c
	motion_control.c
	report.c