Added Values for e and f, because they are used often in GCodes and speed up Extruder a little (will be used later)
This is a bigger patch, it compiles, but i didn't test it this way, because its a backport from my running software splittet in smaller parts for understanding.
Let me explain :
Reason was i had unexplained crashes of edge, all very time dependend. What i found is, that gcodes are added as a list to a moving block, but i couldn't find, that the used memory was freed after deleting the block. This new version adds a block for every gcode (Robot). Advantage is that the player can stop now on every gcode. But now you have blocks with move information (moving_block) and some without - they need to be skipped in movement calculation (Planner::reverse_pass, Planner::forward_pass, Planner::recalculate_trapezoids).
Block::reverse_pass and Block::forward_pass are cleaned up, because they only need one argument).

What comes along with this is to redesign the Block::pop_and_execute, because we don't pop new gcodes from a list. A Block ends and a new is taken. I moved this to Player::finish(), because it only needs information from player. There is a new flag Player::running instead of looking_for _new_block.
The recursive call's to Block::release are rolled out in Player::finish, because there were access to Block-informations after delting the Block from the queue. Additionally i had some doubts on the mechanism of Looking_for_new_block and new_Block_added, because they can be called at any time. I cannot proove, if this change is a must, but runs fine. The unset flag !Player::running means, that the player is playing not playing a block, the kernel is in idle state. The Player polls the queue for valid blocks. If it find one, he starts plaing and moves to the next valid block in PLayer::finsih, when ther is one available. If not, Kernel is set into idle state and Player::running is unset.
Polling is really not the best, but i found no way to insure that stopping player and adding a new block for playing is done safe - maybe we need to disable interrupts during checking the flags, atomic operations or something like that. I find polling in idle state is quite ok. During test i only had polling only during the first few gcodes, until the queue is filled with blocks, that need some time.