Small improvements in code comments.

During testing I discrovered that EG25-G radio may lose some data during transmission
over Serial AT interface or just freezes and stops responding over Serial AT interface.

When ACK mode is not used, the radio may either return an error:

```
Expected: [+QFUPL: 24312545,fa6b], Actual: [+QFUPL: 17124608,b907

+CME ERROR: 409  // Fail to write the file
]
```

Or it may just freeze on modem_at1 interface and stop responding to AT commands:

```
8:0:34:32|TRACE|RADIO| Sending command [AT]
8:0:34:133|DEBUG|RESULT:

8:0:34:133|DEBUG|Shutting Down
```

This commit implements an alternative, ACK mode for data transmission to prevent data losses.
Data is sent in chunks and the device waits for ACK string from the radio for each chunk.

Added waitResponse overloads to the public interface of ICellularRadio.

Refactored MTS::IO::ICellularRadio::sendCommand. Moved response waiting code to the
MTS::IO::ICellularRadio::waitResponse function.

**Motivation**

In many places in the modern libmts-io implementation there are cases when we need to
wait for some response from the radio without executing or sending any commands.
Such places may wait for some URC messages, acknowledge strings during
data transmission and so on.

One way to handle such cases is to use `sendCommand` with `cmd` argument set to an empty
string. It generally works but according to POSIX:

"If count is zero and fd refers to a file other than a regular file, the results are
not specified."

The other way to handle such cases is to use `isNeedMoreData` callback of `sendCommand`
function to analyze all the data on the fly. But this approach may not work for data
transfers when `sendCommand` and its std::string argument may not be used to store binary
data with null characters within.

This commit moves the "wait for the radio to answer" part to the separate function
which allows reusablity of such a code.

During testing with L4G1 device I discovered some inconsistencies in behaviour between
EG25-G device and EG95 devices (EG95-NA and EG95-E).

EG25-G device that I have on hands does not allow to perform downgrades using delta images.
When there is an attempt to apply a downgrade delta image it behaves as the following:

- radio prints `OK`
- radio prints `+QIND: "FOTA",502`
- radio is not rebooted

While EG95 radios always reboot at least once to apply the firmware image. Even if it is not valid.

Also I noticed that detach from the serial bus may take more than 10 seconds in some rare cases.
Thus we need to wait not a fixed amount of time but until the radio actually detaches from the bus.

This commit attempts to address the findings described above.

Added more strict handling for comma-separated data in URC messages to prevent out-of-bounds reads.

Changes after code review:

1. Handle cases when the number of bytes written is different from the number of bytes requested to transfer.
2. Use fstat instead of lseek to determine the firmware size.
3. Renamed TelitRadio::startWrite and TelitRadio::abortWrite functions to better represent their applicability scope.