drivers/saul: Improved stringification

[maribu]

Contribution description

• Changed declaration of SAUL classes (while keeping the format)
  • Termed "class of SAUL classes" category of SAUL classes in the doc to avoid confusion. (E.g. a SAUL class will now be in category sensor or actuator.)
  • Separate enums for SAUL category and intra-category ID. Numbers will now but auto-assigned by the compiler
• Use constant look-up tables for stringification (one table per SAUL category).
  ==> This saves 512B in .data section of AVR

TL;DR:

Pro:

• Smaller RAM footprint
• No manual management of class numbers

Cons:

• Adding new classes requires changing 2 lines instead of 1 (or 3 lines instead of 2 when counting stringification)

Testing procedure

examples/saul should still work with your favorite board

Issues/PRs references

Split off from #11392

[maribu]

@haukepetersen: Please have a look. This reduces RAM requirements on ATmegas by 512B (or 25% of the available RAM of e.g. the Arduino Uno, the Arduino Duemilanove, or the Arduino Nano). I would love to see this merged.

[maribu]

I'll solve the merge conflicts now

[maribu]

Rebased to solve merge conflict

[maribu]

An underscore followed by an upper case letter is a reserved identifier according to the C standard. I fixed the code to stop using them.

@benpicco: Would you mind to have a look? To me, this PR is super uncontroversial and would be a huge step in getting examples/default compiling again on the bottom end platforms. (E.g. 512B RAM safe on AVR, with only 2048B available on the ATmega328P this is quite a chunk.)

[benpicco]

This is a nice cleanup.
I see no functional changes - please squash.

[maribu]

please squash.

Done. All green :-)