Move verifyAndClear to tearDown method in ISIS Reflectometry unit tests

[rbauststfc]

See discussion on #35942.

The verifyAndClear method in many of the ISIS Reflectometry GUI tests are called as the last step for every test at the moment. This method is needed because the tests create some mocks as member variables rather than local variables (see explanation from Gemma on the linked PR).

Ideally we would refactor these tests to create the mocks as local variables, however after looking into this the level of refactor required combined with the number of test classes affected seems too much work for the improved maintainability. Instead, moving verifyAndClear into a tearDown method and adding a comment to explain why this is required (to help developers that are new to the code) seems a proportionate fix.

Because of the number of test classes affected, this will likely need to be tackled across multiple PRs over several maintenance periods.

• [x] ExperimentPresenterTest
• [x] BatchJobManagerProcessingTest
• [x] BatchJobManagerWorkspacesTest
• [x] BatchPresenterTest
• [x] EventPresenterTest
• [x] InstrumentPresenterTest
• [x] MainWindowPresenterTest
• [x] OptionsDialogPresenterTest
• [x] CatalogRunNotifierTest
• [x] QtCatalogSearcherTest
• [x] RunsPresenterTest
• [x] SavePresenterTest
• [x] ISISJournalTest (not part of the Reflectometry GUI tests, but I think may have been added by LSS)

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had activity in 6 months. It will be closed in 7 days if no further activity occurs. Allowing issues to close as stale helps us filter out issues which can wait for future development time. All issues closed by stale bot act like normal issues; they can be searched for, commented on or reopened at any point. If you'd like a closed stale issue to be considered, feel free to either re-open the issue directly or contact a developer. To extend the lifetime of an issue please comment below, it helps us see that this is still affecting you and you want it fixed in the near-future. Extending the lifetime of an issue may cause the development team to prioritise it over other issues, which may be closed as stale instead.