[LoRaWAN] Accept const uint8_t* on public API

[Kabbah]

The goal of this PR is allowing the caller to pass const uint8_t* parameters to the public methods of LoRaWANNode.

Some LoRaWANNode methods, such as beginOTAA, take buffers as parameters (in this case, the AppKey and NwkKey) with type uint8_t*. However, in many cases, the buffers are not modified and could be specified as const. Not using const makes the caller unable to pass a const uint8_t APP_KEY[16], for example, resulting in a compilation error such as:

error: invalid conversion from 'const uint8_t*' {aka 'const unsigned char*'} to 'uint8_t*' {aka 'unsigned char*'}

In this PR, I focused just on public methods, but there may be other opportunities to use pointers to const elsewhere in the file. Unfortunately, the change leaked into Utils.cpp, as RADIOLIB_DEBUG_PROTOCOL_HEXDUMP calls rlb_hexdump, which also takes a non-const parameter despite not modifying it. It should not change behavior, but if you'd rather avoid changing it, I can undo the const change in setBufferNonces.

[jgromes]

Looks good to me - @StevenCellist maybe this will require some changes in https://github.com/radiolib-org/radiolib-persistence?

[StevenCellist]

Probably, I'm not an expert at the const stuff. I can test for the ESP32 tomorrow, but I dread the moment I have to take out my ESP8266 as I lack one GPIO pin. Overall, looks fine to me.

[Kabbah]

I believe it should have no impact on existing user code, radiolib-persistence included. Using uint8_t appKey[] = { /* ... */ } and such is still allowed, because uint8_t* is promoted to const uint8_t*.

Adding const to the library is like saying "I promise not to modify this buffer", and that is already the case.

[jgromes]

@Kabbah thanks for the additional context - merged, thank you for the contribution!