Docs: split API into Operations and Functions list

[josephjclark]

Summary

This PR changes the docs template so that Operations and Functions feature in two different lists.

This helps make it clear what is an Operation and what is a Plain Old Function

Details

As a bonus fix, indenting on the right hand contents menu has been fixed.

These changes do not affect the adaptor JSdoc at all. It just works out of the box.

Screenshots from a first pass:

Issues

Closes https://github.com/OpenFn/docs/issues/439

Related to #522

Further work

• [ ] Add an @operation jsdoc tag, which marks the doclet public and is used to recognise operations
• [ ] The Operations list doesn't show signatures
• [ ] Put the operation/function summary contents into a table with two columns, so you can see both. Maybe just on desktop windows?
• [ ] Don't show the return type in an Operation signature
• [ ] I think the Operation keyword should feature somewhere in each Operation, like a badge. Clicking it would take you to our best explanation of what an Operation is
• [ ] Improve the summary docs at the top of the Operations and Functions sections (include links)

[josephjclark]

I wonder how the common API fits into this.

I don't want 4 lists - adaptor operations, adaptor functions, common functions, common operations. That's chaos.

We can't "merge" operations and functions from common, because it's confusing.

So maybe we list everything in one list, and perhaps add a* if it comes from common?

[josephjclark]

One of the things with the common API is that, because it's the same for all adaptors, once you know the main common functions, they just sort of get in the way.

So yes, you want to see that the common functions are there. And its critical for new users. But I do think they're second class citizens, or there should be the option to hide them, or something.

[josephjclark]

I wonder if just adding a tag for Operations is a better way to go here. That still leaves namespaces to work out though...