Remove old static documentation function pages (Aggregate/Scalar)

[alamb]

Part of #12740

Is your feature request related to a problem or challenge?

@Omega359 added the infrastructure to automatically create documentation from code in #12668

For a while this will result in a transition period where we have two copies of most function documentation:

1. A "static" one (e.g. https://datafusion.apache.org/user-guide/sql/scalar_functions.html)
2. A "auto generated" one (e.g. TODO WHEN MERGED)

Describe the solution you'd like

Once all the documentation for functions has been migrated to the new auto generated pages, we should remove the static pages

Describe alternatives you've considered

Basically this means for the scalar, window and aggregate functions:

1. Delete the static file docs/source/user-guide/sql/scalar_functions.md
2. Rename the _new files like docs/source/user-guide/sql/scalar_functions_new.md to docs/source/user-guide/sql/scalar_functions.md
3. Update the index page docs/source/user-guide/sql/index.rst to remove the _new entries
4. Update the script dev/update_function_docs.sh so it writes to the scalar_functions.md file

Additional context

We need to complete porting all documentation first

[alamb]

I think we are in the position that someone could pretty easily remove the Aggregate and Scalar functions page. We need to wait for #8709 before we can remove the window function one (but @jcsherin and @jatin510 are pretty close)

https://datafusion.apache.org/user-guide/sql/index.html

[Omega359]

My only concern is what to do with the functions that have postgresql-style syntax options (2 of which are still on the scalar doc page):

• extract - it's data_part, but with different syntax
• position - it's strpos, but with different syntax
• substring, it's substr, but with different syntax
• trim, it's one of the trim functions, but with different syntax

Should we put those into the special functions page?

[jonathanc-n]

@Omega359 I'm thinking we can probably put them as aliases?

[Omega359]

That may work though it doesn't help in documenting the difference in syntax. I was also wondering about add an alternative_syntax(...) section to the Documentation struct for functions like these.

[jonathanc-n]

Yeah that could work, I can add an issue for that.

[Omega359]

take