copy: Provide top-level documentation.

This commit adds documentation for the `copy` module, explaining why the
module may require some changes in the objects being copied to behave as
CPython.

Unlike CPython, MicroPython does not provide default implementations for
either `__reduce__` or `__reduce_ex__`, which are used by the copy module
as the fallback methods to create copies of non-trivial objects.  These
methods aren't provided by default to minimise both the footprint of the
interpreter binary and the RAM taken by object instances.

Users who want simpler ways to allow object copies can implement
`__copy__` and `__deepcopy__` instead, as mentioned in CPython's
documentation for the `copy` module.

Arguably the lack of `__reduce__` and `__reduce_ex__` could also be
mentioned in MicroPython's own documentation as part of the differences
from CPython, but it doesn't hurt to mention more module-specific caveats
in here too.  This should, in theory, keep user expectations in check
w.r.t. the behaviour of this specific module.

Signed-off-by: Alessandro Gatti <a.gatti@frob.it>

Author: agatti

python-stdlib/copy/README.md

@@ -0,0 +1,12 @@
+# copy
+
+Copies of non-trivial objects on CPython depend on an implementation of
+``__reduce__`` or ``__reduce_ex__`` being available, with the former method
+being usually added by CPython itself as part of the standard object creation.
+MicroPython, to keep both flash and RAM footprints down, does not provide an
+implementation of ``__reduce__``.
+
+Objects that do not provide either of those methods may implement
+[``__copy__``](https://docs.python.org/3/library/copy.html#object.__copy__) or
+[`__deepcopy__`](https://docs.python.org/3/library/copy.html#object.__deepcopy__)
+to allow the copy operation to succeed.