fix: limit numpy version to fix ReadTheDocs build

[victorgarcia98]

Closes #681

This PR limits the numpy version to <0.1.24 to make it compatible with numba==0.56.4.

Please, let me know your thoughts on this :D

[victorgarcia98]

Running pytest upgrading the dependencies I found another error:

 ERROR  - ImportError: cannot import name 'validate_email_deliverability' from 'email_validator' (/opt/hostedtoolcache/Python/3.9.16/x64/lib/python3.9/site-packages/email_validator/__init__.py)

[nhoening]

Cool!

For the testing of upgraded dependencies,

1. I'm not sure we are now respecting the limits in app.in, as we just do an eager upgrade. I was thinking about a new make target install-upgraded-deps.
2. This prolongs our CI minute usage, per each push. Ideally, I'd only use this upgrade setting when a new PR is made, not on each push. Not sure how exactly, though.

[nhoening]

You could also split the hotfix from the CI feature, if you want.

[nhoening]

On checking if we still support the latest versions of dependencies (the upgrade case) only once per PR:

I see that we mostly run every action twice as we specify on: ["push", "pull_request"]. The latter contains many events in the PR's life, but they should only be executed when we open the PR:

By default, a workflow only runs when a pull_request event's activity type is opened, synchronize, or reopened.

However, as I'm checking a few PRs, this is not what is happening in our case.

We should stop using pull_request in a bare manner here, and try this instead:

on:
  pull_request:
    types: [opened, reopened]

Then, maybe the best approach to use the upgrade variable (or we'll call it test-upgrades-dependencies) by setting its truth value to github.event.action == 'opened'. I didn't find this exact example, so I'm not certain this is how that check should look like ― I read here.

Another interesting example is how to run a job when a PR is approved, but that works a little differently. Just an inspiration.

[nhoening]

• numba is not a first-level dependency of ours, so for a future Dev to release this limit, we should comment which library initially is responsible (likely the one that depends on numba, or even a specific version of numba).
• can you also make the PR description simpler again?

[Flix6x]

No changelog entry required imo. If anyone disagrees, feel free to place back the label.

[Flix6x]

Should this be backported, actually?