[ENH] Add sphinx event to add capability table to estimators' docs individually

[inclinedadarsh]

Reference Issues/PRs

Fixes #1430

What does this implement/fix? Explain your changes.

Add html-page-context callback event to add capabilities table individually to each estimators' docs

• implement _add_estimator_capabilities_table function
• use that function with html-page-context sphinx event callback

Does your contribution introduce a new dependency? If yes, which one?

No, it doesn't.

PR checklist

For all contributions

• I've added myself to the list of contributors. Alternatively, you can use the @all-contributors bot to do this for you.
• The PR title starts with either [ENH], [MNT], [DOC], [BUG], [REF], [DEP] or [GOV] indicating whether the PR topic is related to enhancement, maintenance, documentation, bugs, refactoring, deprecation or governance.

[aeon-actions-bot]

Thank you for contributing to aeon

I have added the following labels to this PR based on the title: [ $\color{#FEF1BE}{\textsf{enhancement}}$ ].

The Checks tab will show the status of our automated tests. You can click on individual test runs in the tab or "Details" in the panel below to see more information if there is a failure.

If our pre-commit code quality check fails, any trivial fixes will automatically be pushed to your PR unless it is a draft.

Don't hesitate to ask questions on the aeon Slack channel if you have any.

PR CI actions

These checkboxes will add labels to enable/disable CI functionality for this PR. This may not take effect immediately, and a new commit may be required to run the new configuration.

• Run pre-commit checks for all files
• Run mypy typecheck tests
• Run all pytest tests and configurations
• Run all notebook example tests
• Run numba-disabled codecov tests
• Stop automatic pre-commit fixes (always disabled for drafts)
• Disable numba cache loading
• Push an empty commit to re-run CI checks

[inclinedadarsh]

@all-contributors please add @inclinedadarsh for code

[allcontributors]

@inclinedadarsh

I've put up a pull request to add @inclinedadarsh! 🎉

[baraline]

Seems like the issue was about commit from your side somehow, as merging main fixed it.

One last bit that we should resolve is to have uniform format between what your script generate and the format in the files where capabilities are already listed. I think the simplest would be to remove the existing ones and only keep those generated by the script. Would that be OK for you @SebastianSchmidl ?

[SebastianSchmidl]

Seems like the issue was about commit from your side somehow, as merging main fixed it.

One last bit that we should resolve is to have uniform format between what your script generate and the format in the files where capabilities are already listed. I think the simplest would be to remove the existing ones and only keep those generated by the script. Would that be OK for you @SebastianSchmidl ?

Sure, the more automation the better 👍

[inclinedadarsh]

This sounds good.

Should I remove all the capabilities table from AD modules that were added manually @baraline ?

[baraline]

Yes please :)

[SebastianSchmidl]

Some information in the manually added AD tables is not captured via tags, e.g.

       * - Input data format
         - univariate
       * - Output data format
         - anomaly scores ◀️ **not in tags**
       * - Learning Type
         - unsupervised ◀️ **not in tags**

I think, we should move this information to the tags then. We just do not have a standard way to do this currently.

I would propose the following:

• for the learning type, we use one-hot-encoding similar to the other capabilities (a single method can have multiple supported learning types)
• for the output data format, we just use a single string-tag

E.g. for DWT-MLEAD:

    _tags = {
        "capability:univariate": True,
        "capability:multivariate": False,
        "capability:missing_values": False,
        "capability:unsupervised": True,
        "capability:semi-supervised": False,
        "capability:supervised": False,
        "output_format: "anomaly scores"
    }

@MatthewMiddlehurst is this compatible with the original design of the tags and the other modules?