Replace stpcpy() with strlcpy()

[krader1961]

There are seven uses of stpcpy(). They result in warnings from the compiler when building on OpenBSD. We now detect if the platform has strlcpy() and if it doesn't provide a fallback implementation. So those uses of stpcpy() should be changed to use strlcpy().

Yes, I have argued in the past that it doesn't matter whether stpcpy() or strlcpy() is used as they both require care in their use. They simply have different failure modes. But after some research and thought I concluded that strlcpy() is slightly less dangerous. And there are already plenty of uses of strlcpy() in this project. Better to standardize on that API to minimize potential misunderstandings.

[krader1961]

See also issue #266 where the merits of strncpy() versus strlcpy() was discussed.

[krader1961]

Three of the seven remaining uses of stpcpy() are in optget.c. That function is invoked from one place in the same module. And the calling function is over 1000 lines long! Why should we continue to pay the cost of maintaining the optget.c module? It's not essential to the functionality of ksh. Switching to the now standard getopt_long() would greatly simplify the project. The primary reason I'm pointing this out is that it affects our decisions about #507. Switching to a modern (i.e., not troff based) solution to the documentation implies that functions like optget() should be replaced with the industry standard getopt_long() and alternative mechanisms for displaying help text and man pages employed.

[krader1961]

I've unassigned myself because most of the existing uses of stpcpy() do not readily lend themselves to replacement by strlcpy() other than in a manner that does not improve safety of the code. Some, if not most, of those instances are due to assumptions about how unrelated strings are stored (see issue #828). So while I believe this is an important issue there are far too many other issues of equal, or greater, priority that need to be addressed.