Strange `std::begin(x)` and `std::end(x)` with c-strings

### Basic Infos

- [x] This issue complies with the [issue POLICY doc](https://github.com/esp8266/Arduino/blob/master/POLICY.md).
- [x] I have read the documentation at [readthedocs](https://arduino-esp8266.readthedocs.io/en/latest) and the issue is not addressed there.
- [x] I have tested that the issue is present in current master branch (aka latest git).
- [x] I have searched the issue tracker for a similar issue.
- [x] If there is a stack dump, I have decoded it.
- [x] I have filled out all fields below.

#### Platform

- Hardware: ESP-12
- Core Version: 612e7ffd7fb398fc2cdcf8bd1d177b75d997d46c
- Development Env: PlatformIO
- Operating System: Windows

### Settings in IDE

Defaults

### Problem Description

Using `std::begin` and `std::end` or the equivalent `&buf[0]` and `&buf[Size]`, *sometimes* the resulting string pointer happens to be at a different location than expected. Using `addresses(std::begin(...), std::end(...));` outside of the template produces the same results. Referring to `&buf[Size-1]` aka `'\0'` does not result in the incorrect pointers though.

Originally noted in the https://github.com/earlephilhower/newlib-xtensa/issues/19#issuecomment-921884356, but it might be something different than string suffix merging / anything related to the toolchain or libc? (and not to continue an already long issue thread. plus, I hope I have not broken toolchain installation somehow)

### [MCVE](https://stackoverflow.com/help/mcve) Sketch

```cpp
#ifdef NATIVE
#include
#include
#include
#else
#include
#endif

void addresses(const char* const begin, const char* const end) {
::printf("%p:%p -> (%u)\n", begin, end, end - begin);
}

template
void addresses(const char (&buf)[Size]) {
addresses(std::begin(buf), std::end(buf));
}

void test() {
addresses("");
addresses(",");
}

#ifndef NATIVE
void setup() {
Serial.begin(115200);
delay(1000);
::puts("\n\n\n");
test();
}

void loop() {
delay(100);
}
#else
int main() {
::puts("\n\n\n");
test();
}
#endif
```

### Debug Messages

```
0x3ffe87e0:0x3ffe87e1 -> (1)
0x3ffe87e1:0x3ffe87dd -> (4294967292)
```
Which is not the expected result. Inspecting the binary, "," is actually at the 0x3ffe87db as one would expect from the `end` (one past the last element of array of 2 elems)