[WIP] Remove datastore arg from models since it is already in the config file

[matschreiner]

Context

So this is a WIP MR, and I'm not sure we are interested in this design at all, I just made the MR to save the work for later if we want to pick it up.

I've been looking randomly through the codebase to see how everything is working together - I noticed that instantiating the model is quite hard—see this example. This complexity makes it difficult to test and reuse the model outside of the main training script.

Issue

There is some redundancy in how the model datastores are passed to the model during instantiation. Specifically, the model:
Accepts a NeuralLAMConfig, which includes both datastore_path and datastore_type.
Also takes an already instantiated datastore object as an argument.
This means the model effectively gets the same information from two different sources, leading to unnecessary complexity.

Proposed Change

To streamline instantiation, I removed the datastore from the model's arguments and instead let the model instantiate it internally based on the provided config. This should reduce redundancy in argument passing and make it easier to instantiate the model for usage in different scripts.

Thoughts

I think that the model should not have a datastore as a member since it introduces a tight coupling between model and data and is against the core modular philosophy of neurallam

No change of dependencies

Issue Link

< Link to the relevant issue or task. > (e.g. closes #00 or solves #00)

Type of change

• 🐛 Bug fix (non-breaking change that fixes an issue)
• ✨ New feature (non-breaking change that adds functionality)
• 💥 Breaking change (fix or feature that would cause existing functionality to not work as expected)
• 📖 Documentation (Addition or improvements to documentation)

Checklist before requesting a review

• My branch is up-to-date with the target branch - if not update your fork with the changes from the target branch (use pull with --rebase option if possible).
• I have performed a self-review of my code
• For any new/modified functions/classes I have added docstrings that clearly describe its purpose, expected inputs and returned values
• I have placed in-line comments to clarify the intent of any hard-to-understand passages of my code
• I have updated the README to cover introduced code changes
• I have added tests that prove my fix is effective or that my feature works
• I have given the PR a name that clearly describes the change, written in imperative form (context).
• I have requested a reviewer and an assignee (assignee is responsible for merging). This applies only if you have write access to the repo, otherwise feel free to tag a maintainer to add a reviewer and assignee.

Checklist for reviewers

Each PR comes with its own improvements and flaws. The reviewer should check the following:

• the code is readable
• the code is well tested
• the code is documented (including return types and parameters)
• the code is easy to maintain

Author checklist after completed review

• I have added a line to the CHANGELOG describing this change, in a section
  reflecting type of change (add section where missing):
  • added: when you have added new functionality
  • changed: when default behaviour of the code has been changed
  • fixes: when your contribution fixes a bug

Checklist for assignee

• PR is up to date with the base branch
• the tests pass
• author has added an entry to the changelog (and designated the change as added, changed or fixed)
• Once the PR is ready to be merged, squash commits and merge the PR.