Clean up use of "byte" as a type. uint8_t or (C++17) std::byte are better

[dok-net]

Related to #8089

[earlephilhower]

Not a fan of the way Arduino did it, but this breaks Arduino compatibility.

https://github.com/arduino/ArduinoCore-API/blob/173e8eadced2ad32eeb93bcbd5c49f8d6a055ea6/api/Common.h#L151-L153

uint16_t makeWord(uint16_t w);
uint16_t makeWord(byte h, byte l);

Removing byte elsewhere seems fine, but the 2-param makeword seems like it should be moved from unsigned char to byte in WMath.cpp.

[dok-net]

In the light of even, say:

#define lowByte(w) ((uint8_t) ((w) & 0xff))
#define highByte(w) ((uint8_t) ((w) >>; 8))

using uint8_t, I find it all rather inconsistent to begin with. Also, while C++ (at least when I read the specs a long time ago, LOL) was based on type-name, not type-structure, if you like to convince me please explain the difference that it makes, when all the while

typedef uint8_t byte;

lets the compiler cast and then link just fine. My reckoning in this is to get rid of "byte" as much as possible - rationale (byte is used as object ident) was given above.
As a compromise, we could leave Arduino.h as it is ...

By the way, I messed up, doing the ESP32 in kind of at the same time, and didn't fix the return type inconsistency here in ESP8266 Core. I have done that now (fixup and rebase).

There are other indications that this discussion is moot, like (AVR Arduino.h to ESP8266's):

-typedef unsigned int word;
+typedef uint16_t word;

and the AVR Arduino.h and ESP8266 Arduino.h are not really very much alike anymore overall. So keep things straight and simple, let's adapt in Arduino.h to uint8_t, too, please.

[dok-net]

Regarding Arduino compatibility: https://github.com/arduino/ArduinoCore-API
Loads of unrewarding differences to merge, figure out, repair, refactor.

[earlephilhower]

LGTM