Change init logic - remove params from initFOC

[runger1101001]

This is an API change: I propose to remove the params from initFOC.

If you look at the way it works now, the semantics are actually quite complicated - with int being used internally but Direction enum in the params, and the params overwriting the values potentially already set in the object. There's also no way to set direction without also setting the zero angle via the params.

All in all this is quite complex (and has led me to be bug-hunting for the second time now :-( ) so I propose the following change (in this PR):

• the Direction enum is now used internally also instead of int for sensor_direction (this not only has the advantage of clarity, but also gives this field a well-defined size since the enum is defined as uint8_t).
• the params are simply removed from initFOC() - the semantics are now simple: if you want to set the zero angle or direction, then just do so like all the other fields:

  motor.zero_electric_angle = 0.1234; 
  motor.sensor_direction = Direction:CCW;

  if you set them before the initFOC() then the calibration will be skipped. Simple.

• the default Direction:CW and angle NOT_SET are set in the FOCMotor base class, as the initial field values.

I've updated the one example I could find referring to this. If you agree to this change, then I'll update the docs accordingly.

Another small change in this PR: \r is added to the isSentinel() characters, to make things work right even if the user sets the wrong EOL in his console...

[askuric]

I like it, you're right that its better. This was already an implemented behavior, but it was not the one we pushed as a default one. I like that ìnitFOC` stays clean.

In terms of \r I have no real opinions, the only issue that I can see is if we manage well the case when the both are set \n\r. Will this create some issues? I guess no but just in case.

[runger1101001]

So I searched the code for all uses of isSentinel() and from what I can see it should not cause any problems. There are many parts where it tries to convert the remaining string with atoi(), but this was already working with \n or \r - it should be the same for \n\r. And the buffer itself is constant size, it doesn't matter if there's an extra character in there that doesn't get used. The loop in commander.run() will run one extra time for the extra \n but AFAICT nothing will happen. In the end, people should set \n as the line ending...

So I will merge this and update the docs in the next few days :-)