Add README section to run the tests

[SqAtx]

Describe a simple way to get the tests running. This should help clear the confusion around the ModuleNotFoundError: No module named 'GTG.core.info' type of errors you get when just running pytest (see #1141).

Adapted from the explanation at #1036

We can close #1141 and #1142

[Neui]

I think the chosen text puts a bit too much on the "why" rather than "how" to run it in a README file, which should be straight to the point. Additionally, I don't think referencing the GitHub Actions workflow is useful if we already show the commands to use anyway here. (I think there is a mistake regarding build directory.) My suggestion:

### Running the tests

Tests are run using `pytest`.

Currently, gtg doesn't support testing in-place,
but you can copy the required files into your source tree for local development:
```sh
meson setup ./.build  # Generate required files
cp .build/GTG/core/info.py GTG/core/  # Copy required files
```

Then you can run the tests with `pytest` in the repository root.

Also:

1. What about using .local_build created by the launch.sh script instead?
2. Using ln -s to create that link may also be useful so the file "auto-updates".
3. We should include how to run tests for the built version (I think it's ninja -C .local_build test or something, I would need to look into that again)

[diegogangl]

I agree with @Neui 's remarks.

What about using .local_build created by the launch.sh script instead?

Not so sure about this. I think it's better to keep builds-to-run and builds-to-test separate, to avoid any mixups

[SqAtx]

I think the chosen text puts a bit too much on the "why" rather than "how" to run it in a README file, which should be straight to the point.

Fair point. Figured I'd put it here to remind myself of the "why" but you're probably right - there may be a place for such documentation but that place isn't here.

Additionally, I don't think referencing the GitHub Actions workflow is useful if we already show the commands to use anyway here.

The thinking behind it was that if they ever drift apart (i.e. we update the workflow but not the README), the README will still point to an example of a setup that works. That said, the workflow actually does a lot more than this simple setup, so it might not be that relevant.

We should include how to run tests for the built version (I think it's ninja -C .local_build test or something, I would need to look into that again)

Come to think of it, maybe that's what the GHA workflow should be running, even. I'm not too fussed about that right now, just trying to lower the barrier to entry.