Fix issue #4184: The spec should warn about using copy constructors.

Until dlang/dmd#20970 is fixed, we need to be
warning against the use of copy constructors rather than warning
against the use of postblit constructors.

So, I fixed the warning and put both it and the description of what
happens when mixing postblit constructors and copy constructors together
on both the section for postblit constructors and the one for copy
constructors.

I suspect that move constructors merit a similar warning, but I'm not
sure what their current state is, so this just fixes the warning for
postblit constructors and copy constructors.

Author: jmdavis

spec/struct.dd

@@ -1106,6 +1106,26 @@ $(H3 $(LNAME2 field-init, Field initialization inside a constructor))
 
 $(H2 $(LEGACY_LNAME2 StructCopyConstructor, struct-copy-constructor, Struct Copy Constructors))
 
+    $(P $(RED Warning:) The plan is for
+    $(RELATIVE_LINK2 struct-copy-constructor, copy constructors) to replace
+    $(RELATIVE_LINK2 struct-postblit, postblit constructors), leaving postblit
+    constructors only in legacy code. However, because the compiler hooks in
+    druntime which deal with dynamic arrays and associative arrays have not yet
+    all been updated to support copy constructors properly
+    ($(HTTPS github.com/dlang/dmd/issues/20970, issue #20970)), any type that might
+    be used in a dynamic array or associative array should use a postblit
+    constructor rather than a copy constructor. The copy constructor will not
+    be called in all the cases where it should be for the elements of a dynamic
+    array or the keys or values in an associative array. Postblit constructors
+    do not have this problem.)
+
+    For backward compatibility reasons, a `struct` that explicitly defines both
+    a copy constructor and a postblit will only use the postblit for implicit
+    copying. However, if the postblit is disabled, the copy constructor will be
+    used. If a struct defines a copy constructor (user-defined or generated)
+    and has fields that define postblits, a deprecation will be issued,
+    informing that the postblit will have priority over the copy constructor.)
+
     $(P Copy constructors are used to initialize a `struct` instance from
     another instance of the same type. A `struct` that defines a copy constructor
     is not $(RELATIVE_LINK2 POD, POD).)
@@ -1365,14 +1385,25 @@ $(GNAME Postblit):
     $(D this $(LPAREN) this $(RPAREN)) $(GLINK2 function, MemberFunctionAttributes)$(OPT) $(GLINK2 function, FunctionBody)
 )
 
-    $(P $(RED Warning): The postblit is considered legacy and is not recommended for new code.
-    Code should use $(RELATIVE_LINK2 struct-copy-constructor, copy constructors)
-    defined in the previous section. For backward compatibility reasons, a `struct` that
-    explicitly defines both a copy constructor and a postblit will only use the postblit
-    for implicit copying. However, if the postblit is disabled, the copy constructor will
-    be used. If a struct defines a copy constructor (user-defined or generated) and has
-    fields that define postblits, a deprecation will be issued, informing that the postblit
-    will have priority over the copy constructor.)
+    $(P $(RED Warning:) The plan is for
+    $(RELATIVE_LINK2 struct-copy-constructor, copy constructors) to replace
+    $(RELATIVE_LINK2 struct-postblit, postblit constructors), leaving postblit
+    constructors only in legacy code. However, because the compiler hooks in
+    druntime which deal with dynamic arrays and associative arrays have not yet
+    all been updated to support copy constructors properly
+    ($(HTTPS github.com/dlang/dmd/issues/20970, issue #20970)), any type that might
+    be used in a dynamic array or associative array should use a postblit
+    constructor rather than a copy constructor. The copy constructor will not
+    be called in all the cases where it should be for the elements of a dynamic
+    array or the keys or values in an associative array. Postblit constructors
+    do not have this problem.)
+
+    For backward compatibility reasons, a `struct` that explicitly defines both
+    a copy constructor and a postblit will only use the postblit for implicit
+    copying. However, if the postblit is disabled, the copy constructor will be
+    used. If a struct defines a copy constructor (user-defined or generated)
+    and has fields that define postblits, a deprecation will be issued,
+    informing that the postblit will have priority over the copy constructor.)
 
         $(P $(I Copy construction) is defined as initializing
          a struct instance from another instance of the same type.