Clean up GCode synchronization

[ThatWileyGuy]

The buffered/unbuffered/async approach to gcode synchronization seems to work well enough in practice, but there's a lot of cruft left over from before it was implemented. I think a few things need to happen as cleanup:

• make buffered/unbuffered/async into an enum instead of boolean flags
• come up with a sane default for the GCode base class (probably buffered?)
• clean up calls from gcodes directly to the path planner to wait for all paths to complete - most of these are unnecessary
• decide whether we also need a notion of "blocking" and what that should look like

Blocking is interesting - enabling a fan is expected to wait for the path queue to reach a certain point but not stop the path planner while we turn on fan, whereas setting steps per mm needs to wait and block further movement until it completes.

[Wackerbarth]

In general, I agree with the intent. However, I recommend that we reconsider the naming of these properties. What does "buffered" mean? (Buffered with respect to what?) Or, "async"? Surely there is a more descriptive terminology.

We can have separate classes for each behavior mode and rather than repeatedly providing definitions about the classification, use inheritance to provide the details to each specific gcode.

As such, there would be no "default" gcode base. Each gcode would be based on the class which has the appropriate behavior.

Additionally, by doing it by subclassing, the implementation details become significantly less important because they are now delegated to the behavior classes.

A good place to start would be to develop a list of behaviors with example commands (gcodes) that would belong to each behavior class.