Fix Indirect Data Reduction crash when open/close interface multiple times

[robertapplin]

Description of work

This PR fixes a crash when you open Indirect Data Reduction, close it, and then open it again. The presenter for the ISIS Energy Transfer tab was not being destructed because the presenter was being held as a raw pointer. This meant that the when a working changes in the ADS, the OutputOptions held by the presenter were trying to update the widget in the previously deleted interface. The solution was to use a unique_ptr to hold the presenters for the Data Reduction interface.

This PR does two additional things:

• It ensures the OutputOptionsPresenter uses the ADSObserver class rather than implementing Poco observers itself. This is clearer to read, and ensures the same presenter does not subscribe to a poco observer more than once (this can cause issues as seen previously in Fix crash due to subscribing observer twice to notification center #37074
• It ensures the Data Manipulation interface uses unique ptrs to hold their presenters. The crash was not being seen on Data Manipulation because the presenters are QObjects, and get destructed when the parent widget is destroyed

Fixes #37409

To test:

1. Open Indirect Data Reduction. Close it. Open it again
2. No crash!
3. Also try the instructions in the attached issue

This does not require release notes because I believe this was introduced recently when IETPresenter was made to be qt-independent

Reviewer

Please comment on the points listed below (full description).
Your comments will be used as part of the gatekeeper process, so please comment clearly on what you have checked during your review. If changes are made to the PR during the review process then your final comment will be the most important for gatekeepers. In this comment you should make it clear why any earlier review is still valid, or confirm that all requested changes have been addressed.

Code Review

• Is the code of an acceptable quality?
• Does the code conform to the coding standards?
• Are the unit tests small and test the class in isolation?
• If there is GUI work does it follow the GUI standards?
• If there are changes in the release notes then do they describe the changes appropriately?
• Do the release notes conform to the release notes guide?

Functional Tests

• Do changes function as described? Add comments below that describe the tests performed?
• Do the changes handle unexpected situations, e.g. bad input?
• Has the relevant (user and developer) documentation been added/updated?

Does everything look good? Mark the review as Approve. A member of @mantidproject/gatekeepers will take care of it.

Gatekeeper

If you need to request changes to a PR then please add a comment and set the review status to "Request changes". This will stop the PR from showing up in the list for other gatekeepers.

[cailafinn]

Code looking good, just noticed a few places to make use of ref assignment. I'm aware much of this is due for changes when converting to MVP, so I'm happy for that to be maintenance if you think it's too much of a pain to re-run the CI.

Otherwise crashes are resolved, tried many different variations of opening and closing windows, while running etc. and had no crashes.

Just want to check if the crash behaviour is unit-testable?

[robertapplin]

Just want to check if the crash behaviour is unit-testable?

Thanks for the review! Unfortuantely this area is not easily unit testable - I'm hoping this will change in the future when MVP has been completed

[cailafinn]

Amendments to the code look good. Still working as expected without crashing when opening/closing GUIs. Changes to docs unneeded. Not currently unit-testable. Nice work.