Categorise API nodes in Table of Contents

[banchan86]

Motivation
Currently the API TOC only lists all API operators in an uncategorised format which makes it hard for instance to identify Bonsai workflow operators from other supporting classes. Bonsai package developers might also wish to group them in a different way or hide certain classes. Referenced in bonsai-rx/docs#85.

Proposed Solution
For a while it seemed like there was no easy way to do this in docfx, but recently @cjsha found a solution using the docfx templating system which was implemented for Openephys Onix1 and can be adapted for general Bonsai packages. It involves sharing the API RawModel mref files globally which can then be processed by the TOC document processor.

Alternative Solutions
There have been several proposed solutions in the past that have been discussed:

1. Docfx categoryLayout option - this option groups operators into classes and enums, but it requires changing the output format of the API pages into one that does not support custom API templates. It is also limited in the types of categories and requires modifying the base docfx library to add additional categories. Referenced in [Feature Request] Support custom API page categories dotnet/docfx#9998.

2. Replacing automatically generated TOC with manually generated TOC - this option requires manual customisation for each separate package and needs to be manually updated when new classes are added to a package and thus may be undesirable for future development. Referenced in Potential workaround for custom API TOC page neurogears/onix-docs#1.

Additional Context

• The lowest hanging fruit is to simply group nodes by their existing Bonsai workflow-element (source, sink, combinators, transforms) and put the rest into a misc or helper classes group. However we can discuss if we should recognise other common categories (eg Attributes or TypeConverters or Visualizers).

• With the templating engine in place, Bonsai package developers can also further customise the TOC by providing their own toc.extensions.js to override the categories that we have defined by default.

• We should also discuss if we want to modify the TOC to hide accessory classes (like configuration classes), but currently all TOC items are present.