Use more strlcpy() in two-phase transaction code

Use more strlcpy() in two-phase transaction code

This commit replaces two calls of strcpy() and one call of strncpy() to
use strlcpy(), which are patterns that static analyzers (mostly LLMs, it
seems) have been complaining regarding buffer overflow risks.

The existing calls are safe, here are more details for each one of them:
- MarkAsPreparingGuts()'s strcpy() was guarded by MarkAsPreparing().
- PrepareRedoAdd()'s strcpy() is safe because the record-level CRC check
prevents corrupted data from reaching it unless intentionally
crafted.  The replay code also assumes that the GID is within the allowed
bounds, as WAL records are trusted.
- Similarly, ParsePrepareRecord() stores its GID in a buffer bounded by
GIDSIZE while trusting the length provided by the record.

As a result, these changes are purely cosmetic.  They adopt a more
defensive coding style and should also silence some of the static
analysis reports received recently.

Author: Matt Suiche <matt@tolmo.com>
Discussion: https://postgr.es/m/CAGf6Lfx2kbQfcEnCi99V2i65JSWD6ij_E29F+UkY=TyMUyeG6A@mail.gmail.com