Split standard library docs into multiple pages

[bentsherman]

@christopher-hakkaart I tried splitting up the stdlib page into multiple sections. Moving each type to its own page isn't feasible right now because it creates too many levels of headings. So instead I just split at the level of constants/functions/types, which reduces the max length by a little bit.

To go all the way, I think we would need to split the "Reference" section into multiple sections:

Language

• syntax
• stdlib
• feature flags
• processes
• channel factories
• operators

???

• CLI
• config options
• environment vars

I'm not sure what to call the second section but they seem loosely related. Configuration? User interface? There is also the concept of a "Runtime API" (e.g. the APIs used by plugins) that will need to fit in here one day, somehow.

Anyway, if we can find a sensible hierarchy here, maybe we can move this forward

[netlify]

✅ Deploy Preview for nextflow-docs-staging ready!

Name	Link
🔨 Latest commit	3917b81
🔍 Latest deploy log	https://app.netlify.com/sites/nextflow-docs-staging/deploys/681222b724a75c0008673b95
😎 Deploy Preview	https://deploy-preview-5993--nextflow-docs-staging.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[christopher-hakkaart]

Love the direction. I'll do some research and thinking and try to come up with some options as well.

[christopher-hakkaart]

A few thoughts:

• I really like splitting the pages out. I think we should be doing more of this across the nextflow docs to keep pages at a reasonable size.
• The stlib page feels like an index or landing page for stdlib constants, functions, and types. I like this in principle, but I find that having the Groovy and Java classes below detracts from these links and makes them easy to miss. I'd propose making a page for Groovy and Java classes, adding a line of text, and then having a separate bullet point just for this. The page is short, but the text could be expanded to explain each category/page and then list the pages.
• Some loose naming for the sections described above could be Language reference and Runtime reference. I'm still simmering on other options. I'm always a little conflicted about moving stuff around too much, one side, it's good to test and work out if it improves navigation, the flip side is confusing users who can't find moved content.
• This could be expanded to other pages, process reference is an easy win.
• Eventually, I could see pages like the stlib across the nextflow docs and using cards with descriptions to help direct users to the right content. See Docker docs and MultiQC as examples.

I got a bit excited and pushed my proposal to your branch. I've reverted, but you'll be able to see what I was proposing in the commits.

[bentsherman]

I introduced the concept of "namespaces" as a better way to document the built-in constants and functions. We can build on this language as we expand the standard library.

I like your idea of moving the groovy/java classses to a separate page.

I think I'm happy with the changes at this point. Not as much splitting as I wanted but it's a good incremental improvement. I will think about splitting up the types separately. We should be able to do it without adding any more sub-headings

I also like the idea of splitting up the process directives, I will try that in a separate PR

[christopher-hakkaart]

This all looks really good. Some minor suggestions. Non-blocking.