PID redesign

[gergelytakacs]

Redesign of the PID functionality to increase usability and scalability. This is, in essence a continuation of #13 .

@rkoplinger suggested (in person) to move PID functionality in its own class. This, I have initially rejected for I have thought that having something like AutomationShield.pid() would simplify the use of the library from the end users perspective. Then came all the versions for absolute and incremental inputs, then the discrepancies between the tuning constants (Kp, Ki, Kd or Kp Ti Td) and of course saturation, integration windup and all that. @rkoplinger was right, so I have changed my mind.

I think that the PID functionality needs to be redesigned for these reasons. Here are some ideas (not necessarily instructions) how to change it:

• Move PID to its own class PIDClass (constructed as PID)
• Let the PID functionality have its own .h and .cpp files for easier maintenance
• The user could set gains or time constants independently, eg, there could be functions such as PID.tuningKp() and PID.tuningKi... (Can you do PID.tuning.Kp()? that would be even better)
• The user should be able to choose (switch) between the incremental and absolute forms, for example by calling someting like PID.beginAbsolute() (Again, can it be PID.begin.absolute()`) and counterparts.
• The hard saturation and windup function should be called independently and it would not only take the boundaries, but also initialize the proper PID version and code... (PID.windup(float hi, float low) )
• These things could be a sort of an initialization, then the final call could be something like PID.compute(float error) or something like that.

These are just ideas, please contribute.

[gergelytakacs]

You guys did an awesome job, love it. @rkoplinger / @kulho

There are two "leftover" branches. I created pull requests but you need to decide what can (and should) be pulled into master.

[gergelytakacs]

The leftover branches are cleared. This is a quite nice version now.