Describe the outcome that is desired.
We want to refactor the Quasi tab in the Inelastic Bayes Fitting interface so that it utilizes the MVP design pattern. Using MVP has several benefits including:

Separation of Concerns: MVP enforces a clear separation of concerns within your application, making it easier to manage and maintain. It divides the application into three distinct components: Model, View, and Presenter, each with specific responsibilities.

Testability: MVP promotes testability by isolating the presentation logic in the Presenter. This separation allows you to write unit tests for the business logic without involving the user interface, making it easier to verify the correctness of your code.

Reusability: MVP can enhance code reusability, as the Presenter, which contains the application's logic, can often be reused with different views. This can be particularly useful in cases where you need to provide multiple user interfaces for the same application logic (e.g., web and mobile apps).

Maintainability: The separation of concerns in MVP makes it easier to maintain and extend your codebase. Changes to the user interface (View) do not require modifying the underlying logic (Presenter) and vice versa. This can reduce the risk of introducing new bugs when making updates.

Describe any solutions you are considering
Rather than having a single class, currently called Quasi, we want three classes:

QuasiView, QuasiModel and QuasiPresenter

Testing instructions
Testing instructions for this tab can be found on this page:
https://mantidproject.github.io/developer/Testing/Inelastic/BayesFittingTests.html

Acceptance Criteria
A few things to look out for (this is not an extensive list):

• Qt is only used in the View
• The Presenter does not have any Qt connections
• The model contains the logic
• The model and view are passed into the presenter constructor
• The model and view do NOT communicate directly.