refactor: Master term models

[trisyoungs]

This PR moves the responsibility of adding / removing master terms to the relevant model, rather than leaving this the job of the GUI at the calling point.

A significant change here is the storage of a reference to CoreData within the base MasterTermModel. Comments welcome on this, but the allows easy access to the addition / removal of terms, as well as permitting a nice clean up of code throughout all the models.

[rprospero]

Using the CoreData as the parameter on the constructor certainly simplifies things. The one bit that makes me nervous is that requiring a parameter means that the type cannot be created in QML. Creating the type in the QML itself can be useful (e.g. what we do with AddForcefieldDialogModel in AddForcefieldTermsDialog.qml). However, we're not doing that anywhere with the master terms and it doesn't seem likely that we will, so we should be okay.

I'm bringing this up because I've been thinking about the structure of the models for the pure QML GUI. I'm imagining that we'll ultimately need a bunch of higher level models (e.g. DissolveModel, CoreDataModel) and that these might be able to return inner models (e.g. a CoreDataModel having a function that returns its MasterAngleModel). That way the models can be passed around as parameters within the QML and can be passed into any other bespoke models that may need them.

[rprospero]

There's a bunch of places where we might want to add some error logging and/or dialogs, but it looks good otherwise.

[trisyoungs]

Using the CoreData as the parameter on the constructor certainly simplifies things. The one bit that makes me nervous is that requiring a parameter means that the type cannot be created in QML. Creating the type in the QML itself can be useful (e.g. what we do with AddForcefieldDialogModel in AddForcefieldTermsDialog.qml). However, we're not doing that anywhere with the master terms and it doesn't seem likely that we will, so we should be okay.

I'm bringing this up because I've been thinking about the structure of the models for the pure QML GUI. I'm imagining that we'll ultimately need a bunch of higher level models (e.g. DissolveModel, CoreDataModel) and that these might be able to return inner models (e.g. a CoreDataModel having a function that returns its MasterAngleModel). That way the models can be passed around as parameters within the QML and can be passed into any other bespoke models that may need them.

Yes, this is a very valid concern, and not one which I had thought about when I made that change! However, your suggestion of a top level model encompassing either or both of Dissolve and CoreData matches closely with what @jws-1 had started tinkering around with for "Workflow 2.0", so I think we are all of the same mind going forward.