Improve firmware_runtime.c significantly

[nick-parker]

I wrote about this in #development a couple months ago but just now remembered to make the PR.

The current direction pin behavior is to set every pin either high or low every loop of the firmware, even if no pins have actually changed. Also, the higher level firmware doesn't remember direction pin status, and so it only ever sends high direction bits for the axes which are actively being stepped in a given loop iteration. This has two major downsides:

• Compound moves will produce square waves on the direction pins when they should just set once and leave it until the axis switches direction. This creates unnecessary noise, wastes cycles, and makes the command signals far harder to interpret on a scope / logic analyzer. The square wave output also makes borderline signal conditions for external drivers very hard to debug.

• Since the firmware thinks the direction signals are being updated every loop, it executes the direction setup time delay every loop. Depending on the specific delay parameters this can cut the system's max step rate by 50% or more.

This PR adds a uint8 which remembers the current direction pin values, and diffs that against the commanded values for the set of axes being stepped each loop. If the diff is empty the direction register updates and the direction setup delay are both skipped.

[ThatWileyGuy]

I'm printing with this today.