Prevent using strncpy with src == dest in TupleDescInitEntry.

The C and POSIX standards state that strncpy's behavior is undefined when
source and destination areas overlap.  While it remains dubious whether any
implementations really misbehave when the pointers are exactly equal, some
platforms are now starting to force the issue by complaining when an
undefined call occurs.  (In particular OS X 10.9 has been seen to dump core
here, though the exact set of circumstances needed to trigger that remain
elusive.  Similar behavior can be expected to be optional on Linux and
other platforms in the near future.)  So tweak the code to explicitly do
nothing when nothing need be done.

Back-patch to all active branches.  In HEAD, this also lets us get rid of
an exception in valgrind.supp.

Per discussion of a report from Matthias Schmitt.

src/tools/valgrind.supp

@@ -64,22 +64,6 @@
 }
 
 
-# resolve_polymorphic_tupdesc(), a subroutine of internal_get_result_type(),
-# can instigate a memcpy() call where the two pointer arguments are exactly
-# equal.  The behavior thereof is formally undefined, but implementations
-# where it's anything other than a no-op are thought unlikely.
-{
-	noopmemcpy_internal_get_result_type
-	Memcheck:Overlap
-
-	fun:*strncpy*
-	fun:namestrcpy
-	fun:TupleDescInitEntry
-	...
-	fun:internal_get_result_type
-}
-
-
 # gcc on ppc64 can generate a four-byte read to fetch the final "char" fields
 # of a FormData_pg_cast.  This is valid compiler behavior, because a proper
 # FormData_pg_cast has trailing padding.  Tuples we treat as structures omit