ENH: Consolidate and enhance documentation into the top level functions variants

Following the merge of pygeos into shapely there are many "almost duplicated" functions with similar or different documentation (typically one variant from pygeos and the other from shapely 1.8) also there is no unified docstring conventions and type annotations for most functions.

This issue is to discuss how to consolidate and enhance the documentation in that regard.
My ideas are as follows:

1. Put the full documentation of the functions in the top level functions (these usually work on array like), including parameters, return type and examples, for example shapely.constructive.snap (https://github.com/shapely/shapely/pull/1673). Move all relevant examples from other copies of the function, i.e. shapely.ops.snap (let's call these secondary functions).
2. On the docstrings of the secondary functions (i.e. shapely.ops.snap) leave only a short description and pointer to the main function (i.e. shapely.constructive.snap)
3. Regards documentation, ignore the fact that sometimes the parameter names or order is different between the main and secondary functions (i.e. transform, https://github.com/shapely/shapely/pull/1676) because the user can see how the secondary parameters are mapped to the main function parameter, and also, usually it's just trivial.
4. Add proper type annotations to all the affected functions https://github.com/shapely/shapely/pull/1687
5. Decide on a unified docstring convention https://peps.python.org/pep-0257/ i.e. uniformed documentation of parameter names, types and return type in docstrings - I see that some Sphinx style is used but it's not the "regular style" as described here https://sphinx-rtd-tutorial.readthedocs.io/en/latest/docstrings.html, so for example, how do we describe the function return type ?
6. In case more clarification is needed, copying/adapting extra documentation and examples can be considered from other sources, like libgeos or PostGIS (example: https://github.com/shapely/shapely/pull/1673)
7. This will also avoid the need to update duplicated documentation, like in https://github.com/shapely/shapely/pull/1231

Related to:
https://github.com/shapely/shapely/pull/1402
https://github.com/shapely/shapely/issues/962

@jorisvandenbossche @mwtoews @sgillies @caspervdw
I have a fixed amount of time that I have to invest on this major documentation improvement project... So I really need your advise so I can get started and wouldn't waste my time on efforts that won't get accepted.

I thought to implement the ideas we discuss for some functions at a time and make a PR with one commit per function.

If anyone with writing permissions interested in helping with reviewing and merging the documentation PRs (as well as the related PRs I mentioned above) that would be super helpful, as I'm pretty stuck if they don't get feedback as I don't want to invest more time with consolidating and enhancing documentation for other functions if I'm not sure about what is likely to get accepted.

Related/Semi-related PRs that I would be happy if could get reviewed and merged before I dive in further into the documentation project:
https://github.com/shapely/shapely/pull/1687
https://github.com/shapely/shapely/pull/1682
https://github.com/shapely/shapely/pull/1681
https://github.com/shapely/shapely/pull/1673
https://github.com/shapely/shapely/pull/1676
https://github.com/shapely/shapely/pull/1231 (not my PR, but very long standing and could be helpful while I work on this issue)

Thanks and happy holidays 😃

Start by reviewing the top-level functions such as shapely.constructive.snap alongside secondary functions such as shapely.ops.snap, then read the related PRs 1673, 1676, and 1687. Clarify the accepted docstring convention and annotation scope before changing functions. Done means duplicated documentation is consolidated, secondary functions point to their primary variants, and affected functions follow the agreed documentation and typing conventions.