Move test model into repo instead of submodule

[SJaffa]

Moves the test model and other resources used in testing into a folder within tests, and updates the paths used in tests.

[SJaffa]

We discussed if it is better to
1.have this models submodule or
2. to just have the one example model as a file in the main repo and people can point the code to their own models
I think I prefer option 2 as submodules are just too confusing, but I can't remember what we decided. @tkoskela what do you think?

[tkoskela]

I think in sopt you are right, having one model there for testing is good enough. After all, it's a library and not something people would directly use. I'm not sure I agree with submodules being too confusing, but I agree that submodules in a library that is intended to be used as a building block for applications does add unnecessary complexity. If Jasons's team want to provide more models in the lexci_models repo, it might make more sense to ship it as a part of purify. If we expect most users to manually clone and build purify, then the submodules would be more explicitly visible.

[SJaffa]

Yes that's a good idea to put the submodule in Purify instead as it fits with the structure that SOPT is the general purpose maths part and Purify is the astrophysics specific application, so I think having one model in this repo for testing and then others can be plugged in through Purify.

[tkoskela]

TODO: Instead of updating the submodule, remove it and add the test model to the sopt repo

[SJaffa]

My first instinct was to put the model in the sopt/cpp/tools_for_tests folder as it is only used in the testing, but the images used in tests and examples are in a sopt/images folder which seems inconsistent. @krishnakumarg1984 in the new structure you described yesterday, where would you keep resources (images/models) used in testing?

[krishnakumarg1984]

@SJaffa One place that we can put such binary assets is in a folder typically with a suffix _data.

The folder hierarchy should be such that:

• data files shared across all sub-components should be at the sibling level to these shared accesses, and could be called common_data
• data files unique to each sub-component should be located in a nested folder (e.g. with name forward_backward_data) at a level as close to it's usage by the component.

We can avoid hard coding the relative paths. Instead, we just set target_include_directories and just use the filename alone in the code.