Fix ManualStateFeatureWeighting kwarg in config.yaml in readme (#99)

## Describe your changes

I think this is just a small typo fix! Or perhaps I misunderstood the
usage of this yaml file...


More details if you want the rest of the usual PR template, but I think
most of it is irrelevant to a small docs fix like this :)
<details>

## 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)
- [x] 📖 Documentation (Addition or improvements to documentation)

## Checklist before requesting a review

- [x] 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).
- [x] I have performed a self-review of my code
- [x] For any new/modified functions/classes I have added docstrings
that clearly describe its purpose, expected inputs and returned values
- [x] I have placed in-line comments to clarify the intent of any
hard-to-understand passages of my code
- [x] I have updated the [README](README.MD) to cover introduced code
changes
- [x] I have added tests that prove my fix is effective or that my
feature works
- [x] I have given the PR a name that clearly describes the change,
written in imperative form
([context](https://www.gitkraken.com/learn/git/best-practices/git-commit-message#using-imperative-verb-form)).
- [ ] 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:
- [x] the code is readable
- [x] the code is well tested
- [x] the code is documented (including return types and parameters)
- [x] 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.

</details>

README.md

@@ -145,7 +145,7 @@ datastore:
 training:
   state_feature_weighting:
     __config_class__: ManualStateFeatureWeighting
-    values:
+    weights:
       u100m: 1.0
       v100m: 1.0
 ```