Keep version of magics package consistent in future releases

[dlqqq]

This PR updates the scripts/bump-version.sh script to automatically update the dependency on jupyter-ai-magics to be equal to the current version of jupyter-ai in future releases.

After this change, when a user upgrades jupyter-ai, jupyter-ai-magics will be upgraded automatically. This will prevent issues like #730 from arising in the future, caused by having different versions of jupyter-ai and jupyter-ai-magics in the same environment.

We are already synchronizing the versions of jupyter-ai and jupyter-ai-magics when manually releasing to Conda Forge, so we should be doing the same for PyPI releases.

[dlqqq]

This PR can be tested by running:

# this is how Jupyter Releaser runs the `bump-version.sh` script currently
# see issue #732 for context
cd packages/jupyter-ai
../../bump-version.sh 2.14.0

cd ../..
cd packages/jupyter-ai-magics
../../bump-version.sh 2.14.0

and inspecting the changes in packages/jupyter-ai/pyproject.toml:

[dlqqq]

It looks like #732 is causing a failure in the workflow. Looking into it now.

[dlqqq]

Unfortunately there doesn't seem to be a way to do this with Jupyter Releaser, due to the check-python step. This step runs the following commands:

        # Create the virtual env, upgrade pip,
        # install, and run test command
        util.run(f"python -m venv {env_path}")
        util.run(f"{bin_path}/python -m pip install -q -U pip")
        util.run(f"{bin_path}/pip install -q {dist_file}")

When we bump to a new version in Jupyter Releaser, say 2.14.0, the jupyter-ai-magics==2.14.0 dependency does not exist, and the pip install -q {dist_file} command fails. There's no existing configuration option to disable this.

I am currently evaluating other possibilities for preventing #730 in the future. One option is to vendor jupyter-ai-magics within the jupyter-ai wheel, such that jupyter-ai no longer has a direct dependency on jupyter-ai-magics.

[krassowski]

Just FYI I went through many of the same issues when refactoring https://github.com/jupyterlab/jupyter-collaboration into a monorepo. You might find something useful in jupyterlab/jupyter-collaboration#280, but some are yet to be solved. I think we can make jupyter-releaser work with it with some minor modifications though.