New string-truncation warnings from GCC 15

Several of the buildfarm animals seem to have been updated to
GCC 15 over the past week or so. They are now moaning about
various places where we're intentionally omitting a string
terminator, eg these warnings from scorpion:

scorpion | 2025-09-16 18:39:03 | ../pgsql/src/backend/commands/copyfromparse.c:139:41: warning: initializer-string for array of 'char' truncates NUL terminator but destination lacks 'nonstring' attribute (12 chars into 11 available) [-Wunterminated-string-initialization]
scorpion | 2025-09-16 18:39:03 | ../pgsql/src/backend/commands/copyto.c:109:41: warning: initializer-string for array of 'char' truncates NUL terminator but destination lacks 'nonstring' attribute (12 chars into 11 available) [-Wunterminated-string-initialization]
scorpion | 2025-09-16 18:39:03 | ../pgsql/src/backend/utils/adt/encode.c:152:1: warning: initializer-string for array of 'char' truncates NUL terminator but destination lacks 'nonstring' attribute (513 chars into 512 available) [-Wunterminated-string-initialization]
scorpion | 2025-09-16 18:39:03 | ../pgsql/src/backend/utils/adt/numutils.c:30:1: warning: initializer-string for array of 'char' truncates NUL terminator but destination lacks 'nonstring' attribute (201 chars into 200 available) [-Wunterminated-string-initialization]
scorpion | 2025-09-16 18:39:03 | ../pgsql/contrib/fuzzystrmatch/daitch_mokotoff.c:92:20: warning: initializer-string for array of 'char' truncates NUL terminator but destination lacks 'nonstring' attribute (7 chars into 6 available) [-Wunterminated-string-initialization]

These are not bugs, but it'd be a good idea to silence the
warnings somehow.

Plan A seems to be to do what the warning suggests and add
a "nonstring" marker to these constants. I gather the syntax
is like this:

char a2nonstring[1] __attribute__((nonstring)) = "a";

It's not clear to me how well this approach will play with
non-GCC compilers.

Plan B could be to change the code so that we're not
truncating the implicit \0 characters. It doesn't look
to me like this would involve any large amount of violence
to the logic, but it's a bit less pretty.

Plan B would be a compiler-independent fix, so I mildly favor plan B.

Thoughts?

regards, tom lane