Fixed bug related to very very low feed rates.

- A very very low feed rate command like `G1 X100 F0.01`  would cause
some floating-point round-off error and freeze Grbl into an infinite
loop. To fix it, introduced a MINIMUM_FEED_RATE parameter in config.h
to ensure motions always complete.

- MINIMUM_FEED_RATE is set at 1.0 mm/min by default. It’s recommended
that no rates are below this value, but 0.1mm/min may be ok in some
situations.

stepper.c

@@ -637,7 +637,6 @@ void st_prep_buffer()
           prep.maximum_speed = prep.exit_speed;
         }
       }  
-          
     }
 
     // Initialize new segment
@@ -688,6 +687,8 @@ void st_prep_buffer()
           break;
         case RAMP_CRUISE: 
           // NOTE: mm_var used to retain the last mm_remaining for incomplete segment time_var calculations.
+          // NOTE: If maximum_speed*time_var value is too low, round-off can cause mm_var to not change. To 
+          //   prevent this, simply enforce a minimum speed threshold in the planner.
           mm_var = mm_remaining - prep.maximum_speed*time_var;
           if (mm_var < prep.decelerate_after) { // End of cruise. 
             // Cruise-deceleration junction or end of block.
@@ -853,30 +854,3 @@ void st_prep_buffer()
     return 0.0f;
   }
 #endif
- 
-/* 
-   TODO: With feedrate overrides, increases to the override value will not significantly
-     change the current planner and stepper operation. When the value increases, we simply
-     need to recompute the block plan with new nominal speeds and maximum junction velocities.
-     However with a decreasing feedrate override, this gets a little tricky. The current block
-     plan is optimal, so if we try to reduce the feed rates, it may be impossible to create 
-     a feasible plan at its current operating speed and decelerate down to zero at the end of
-     the buffer. We first have to enforce a deceleration to meet and intersect with the reduced
-     feedrate override plan. For example, if the current block is cruising at a nominal rate
-     and the feedrate override is reduced, the new nominal rate will now be lower. The velocity
-     profile must first decelerate to the new nominal rate and then follow on the new plan. 
-        Another issue is whether or not a feedrate override reduction causes a deceleration
-     that acts over several planner blocks. For example, say that the plan is already heavily
-     decelerating throughout it, reducing the feedrate override will not do much to it. So,
-     how do we determine when to resume the new plan? One solution is to tie into the feed hold
-     handling code to enforce a deceleration, but check when the current speed is less than or
-     equal to the block maximum speed and is in an acceleration or cruising ramp. At this 
-     point, we know that we can recompute the block velocity profile to meet and continue onto
-     the new block plan.
-       One "easy" way to do this is to have the step segment buffer enforce a deceleration and
-     continually re-plan the planner buffer until the plan becomes feasible. This can work
-     and may be easy to implement, but it expends a lot of CPU cycles and may block out the
-     rest of the functions from operating at peak efficiency. Still the question is how do 
-     we know when the plan is feasible in the context of what's already in the code and not
-     require too much more code? 
-*/