Library changes pin mode of A0 to INPUT

Describe the problem

Under the following conditions, the library uses an analog read of pin A0 to seed the pseudorandom number generator:

Board does not has a built-in ECCx08 crypto chip
Board does not have a hardware random number generator

ArduinoIoTCloud/src/utility/time/NTPUtils.cpp

Line 101 in d4ae0a3

randomSeed(analogRead(0));

This analog read puts the pin into INPUT mode.

In addition to use as a ADC, analog pins may be used as digital output pins by setting the pin mode to OUTPUT.

🐛 If the user is using pin A0 as an output, the library will break their sketch by changing the pin mode.

To reproduce

Add the following code to the setup function of an ArduinoIoTCloud sketch that calls ArduinoCloud.getInternalTime() or ArduinoCloud.update():
```
pinMode(A0, OUTPUT);
```

Add the following code to the loop function of the sketch:

static unsigned long blinkTimestamp;
static byte pinState;
if (millis() - blinkTimestamp >= 1000) {
  blinkTimestamp = millis();
  if (pinState == LOW) {
    pinState = HIGH;
  } else {
    pinState = LOW;
  }
  digitalWrite(A0, pinState);
}

Upload the sketch to one of the following boards (tested with UNO R4 WiFi):
- MKR WiFi 1010
- NANO 33 IoT
- Nicla Vision
- Portenta C33
- UNO R4 WiFi
Monitor the state of pin A0 with an LED or meter.

🐛 The pin state stops toggling.

Expected behavior

Library does not interfere with user's ability to use pin A0 as an output.

- OR -

Library's impact on pin A0 is clearly documented.

Library version

d4ae0a3

Additional context

Originally reported at https://forum.arduino.cc/t/a0-pin-behavior-uno-r4-wifi/1238998

Workaround

Add the following code to the loop function of your sketch:

  static bool pinModeRestored = false;  // Track state to avoid unnecessary calls to the fairly slow ArduinoCloud.connected()
  if (!pinModeRestored && ArduinoCloud.connected()) {
    pinMode(ledPin, OUTPUT);
    pinModeRestored = true;
  }