BREAKING - analogWriteRange 8-bit default

[earlephilhower]

Matching standard Arduino cores, make the default analogWrite() take
values from 0...255. Users can always use the analogWriteRange() call
to change to a different setup.

Fixes #2895

[devyte]

This isn't quite right.

1. We need to have an implementation of analogWriteResolution(int bits), where bits goes from e.g. 4-10 or whatever, which maps to 0-15 - 0-1023 range. That doesn't mean remove the current analogWriteRange().
2. analogWriteRange() needs to have the upper bound checked.
3. The init of the default range needs to be changed to be 255 instead of 1023, that part is correct, but...
4. We should either have:

• PWMRANGE represent our max capability and have a second define that is the default, e.g.: PWMRANGEDEFAULT
  or
• have PWMRANGE represent the default of 255 and have a second define that is the max of 1023, e.g.: PWMRANGEMAX

5. PWMRANGE doesn't seem to exist in Arduino land, but that's ok
6. do we need a res bits getter? I couldn't find anything looking at other core depots

[earlephilhower]

1. We need to have an implementation of analogWriteResolution(int bits), where bits goes from e.g. 4-10 or whatever, which maps to 0-15 - 0-1023 range. That doesn't mean remove the current analogWriteRange().

DONE

2. analogWriteRange() needs to have the upper bound checked.

DONE

3. The init of the default range needs to be changed to be 255 instead of 1023, that part is correct, but...
4. We should either have:
* PWMRANGE represent our max capability and have a second define that is the default, e.g.: PWMRANGEDEFAULT
  or
* have PWMRANGE represent the default of 255 and have a second define that is the max of 1023, e.g.: PWMRANGEMAX
1. PWMRANGE doesn't seem to exist in Arduino land, but that's ok

I suggest a different route: drop the macro. It doesn't track the current state of the machine and it's non-standard.

2. do we need a res bits getter? I couldn't find anything looking at other core depots

I say no. The number of bits of PWM resolution is not something that varies over time once set up. No good use case I can see for pulling it out. Would need same thing for range, and what happens when log2(range) has a fractional bit (i.e. analogWriteRange(1000);?

[devyte]

My one concern is that there is no way to tell whether the range/scale setting succeeded from the call itself (no return value), nor is there a getter to check the current value. That's certainly not a problem for cross-core code, because that functionality isn't part of the reference, but still.
I think the docs need to be updated with the min/max values accepted. I can handle that in a separate PR.
Approving.