Extensions release

[barneydobson]

Issue to discuss finalisation of the new extensions ability.

Below copied from #99

Within #97 - @dalonsoa

• [x] Create extensions_register
• [x] Create register_node_method (optional arg for sub_object).
• [x] Add apply_decorators
• [x] Tests (make tests that can be used in docs)

Within this PR - @dalonsoa

• [x] Implement sequence above
• [x] Tests (make tests that can be used in docs)

Close #54 , make a new PR - @liuly12

• [x] Keep the custom orchestration stuff, bin else

Enable custom subclasses

• [x] #108

Documentation (new issue)

• [ ] Overview of all new functionality (overrides, subclassing, decorators). - @dalonsoa
• [x] Enable decoration of handlers (easy to code - a distinct decorator, e.g., register_node_handler) - us to revisit
• [ ] update documentation for 'customise interactions' and 'river reservoir'. @barneydobson
• [ ] Take down old documentation on customisation ('customise a node').
• [ ] Release here! @dalonsoa
• [ ] Longer term issue to update customise a node.

[barneydobson]

@dalonsoa did we have a plan to add custom classes - I know it can be done by updating the registry but there's no way to enter those in the normal config use. You could add them to be loaded by load_extension_files - but this would need to take place before add_nodes since the subclasses will need to have been registered before that point

[dalonsoa]

I don't remember if we ditched the idea, or just forgot to include it in the plan above. In any case, it should be as simple as moving this line:

https://github.com/ImperialCollegeLondon/wsi/blob/61573a9d2e1997f9d2189a93f3cfbdf9c915638e/wsimod/orchestration/model.py#L223

To before adding the nodes. The extensions files can have decorated stuff but also extra classes, so they all should be "registered" together. I don't think there's any reason for loading the extension files at the end rather than at the beginning.

[barneydobson]

I will add that to the list of tasks above