Small Refactor of MachineModel to facilitate tests

[Quincunx271]

By allowing MachineModel to be constructed by a SpecsBuffer rather than a file, we can easily get a MachineModel in any tests that have one as a dependency.

---

There are bigger ways to refactor the MachineModel that would definitely improve things, but if the focus is making the minimal change needed to enable more widespread unit tests, this is probably the simplest possible change.

[jrbyrnes]

I don't really have any major comments on the implementation of this PR as it largely looks fine. However, I do have a general comment that may or may not be outside the scope of this PR:

It seems to me that in order to get the most use out of this feature, we would want the model being tested to refer to the same model we are using. However, it looks that in this PR we still load the machine model from a file when constructing ScheduleDAGOptSched, therefore in order to test and run the same machine model, we would need to maintain two configs. The immediate solution that comes to mind is to construct the MM for ScheduleDAGOptSched as done in simple_machine_model_test.cpp and removing the machine model config file altogether. This, though, leads to a less friendly UI to changing machine model params (e.g. involves re-compilation), and may not be worth implementing.

[Quincunx271]

That's an interesting and quite good idea, which is out of scope for this PR. The idea here is to make as small of a change as possible in order to enable unit tests.

These unit tests often won't care about the machine model, so having a simpleMachineModel() that can be entirely different from the actual machine model can make sense. Other unit tests might care about the machine model, but then they would probably want to be able to control it to test the interaction of a feature with the machine model.

---

I really do like the idea, though, something like:

const MachineModel DefaultMachineModel = {
    // Whatever struct initializer needed to set this up
};

We could make it so that the file is still possible, e.g. via a commandline flag, by having a parser that outputs this MachineModel. But any changes to the default model would be in the code. And common alternative models can also be builtin to the code.

[Quincunx271]

I'm going to pull this idea of the ideal refactor into an issue. Is this PR good to merge?

[jrbyrnes]

I'm going to pull this idea of the ideal refactor into an issue. Is this PR good to merge?

I like your variant which blends together the encoded MachineModel and config file, and also agree that it should be its own separate issue.

This PR looks good to me.

[Quincunx271]

Helps enable #177