Align the documentation for both `list.sort` and `sorted` since the
latter's C implementation delegates to the C implementation of the
former, in both docstrings, the library docs, and tutorial.

Add a note about how reverse and sort stability interplay, as
this is an easily forgotten edge case and may not necessarily always be
desired.

bltinmodule.c, listobject.c.h:

* Instead of saying "equal elements" in the note about sort stability,
  we standardize on the "compare equal" phrasing from functions.rst,
  which is more precise phrasing that acknowledges that sorting is
  controlled by `key`.

* "ascending or descending" is dropped from the explanation of `key` in
  `list.sort`, because that's controlled by `reverse`, not `key`.

library/functions.rst:

* Fix the type signature of `sorted`.
* Redirect the documentation to `list.sort`.

library/stdtypes.rst:

* Fix the type signature of `list.sort`.
* Replace the "as if each comparison were reversed" language with
  "descending order" for consistency. (Also, technically reversed isn't
  quite true: == comparisons aren't reversed ;).)

tutorial/datastructures.rst:

* Point the reference for `list.sort` to `list.sort`, instead of
  `sorted`.

The set of modified files/locations was determined using:

    grep -C3 -rnE '`(list\.sort|sorted)`' . | grep -v 'howto/sorting\|whatsnew'

The example of sort stability is included in functions.rst
but omitted from the docstrings deliberately: you can only really get to
it via `help()` or `pydoc`, which I suspect tend to be used by people
who know what sort stability is. (Incidentally, in the discussion on
pythonGH-8516, the last update to the list.sort docstring, rhettinger
also expresses the POV that further discussion of sort stability belongs
in extended docs like FAQs/HOWTOs.)