Use RunWidget in Inelastic Corrections

[robertapplin]

Description of work

The RunWidget is now used on the tabs of the Inelastic Corrections interface. It isn't used on the Calculate Paalman Pings tab because this tab is now deprecated and will probably be removed in the future.

Part of #37381

To test:

Follow the test instructions here https://developer.mantidproject.org/Testing/Inelastic/CorrectionsTests.html

This does not require release notes because this is a maintenance change

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.

[robertapplin]

• I see the UserInputValidator hasn't explicitly define a destructor function, wouldnt't it be better to do so?

Thanks for testing, yes I think that would be a good idea

[robertapplin]

• There are still many instances of using UserInputValidator in inelastic that don't use unique pointers, is there any reason why you choose to use unique pointer in some cases only? or is it a refactoring you have planned?

That is a good question, because what is happening is a little bit nuanced. So the unique pointer is created in the RunPresenter::validate() method, but can't be passed through the code as a unique pointer to the IRunSubscriber::handleValidation method because I would need to std::move it to do this. In this case I don't want to transfer ownership of the unique pointer because the RunPresenter::validate() method wants to use the UserInputValidator after returning from the IRunSubscriber::handleValidation method. In this case it is ok that I'm using raw pointers to pass the validator through to the IRunSubscriber::handleValidation method because they are non-owning raw pointers (i.e. the lifetime of the object is correctly managed by the unique pointer in the RunPresenter::validate() method)

I agree that this isn't immediately clear - perhaps a future task would be to start using shared pointers to pass the UserInputValidator through to the IRunSubscriber::handleValidation method. This would make it easier to see that the lifetime of the UserInputValidator is safely managed. The only downside would be that it would be easy to make unnecessary copies of the shared pointers without realising