bug#42296: 27.0.91; Correct manual entry for 'concat' w.r.t. allocation [PATCH]

[Drew Adams <drew.adams@oracle.com>]

> >  This function does not always allocate a new string.  Callers are
> >  advised not rely on the result being a new string nor on it being
> @code{eq}
> >  to an existing string.
> >
> >  In particular, mutating the returned value may inadvertently change
> another
> >  string, alter a constant string in the program, or even raise an
> error.
> >  To obtain a string that can be mutated, use @code{copy-sequence} on
> the result.
> 
> Fine with me, with one correction: last sentence will sound better if
> reworded like this:
> 
>   To obtain a string that you can safely mutate, use
>   @code{copy-sequence} on the result.

FTR, I think that the doc of `concat' should really
make clear that it (now, and apparently for a while
now) has this odd (yes) behavior of not guaranteeing
a new string.  Not sure why we made this change, but
I imagine it was in a zeal to optimize.

At a minimum, please make this very clear, and say
explicitly that to ensure that you get a new string
you can use `copy-sequence' (as you've mentioned),
and that you can alternatively use `seq-concatenate':

 (seq-concatenate 'string &rest SEQUENCES)