Add uv override for opencv-python

[philipqueen]

The original motivation for this PR (below the dotted line) was invalid - see the discussion on my uv issue. However, it may still be useful for development using uv.

This PR would allow local development using uv to avoid the opencv conflict. Simply running uv pip install -e. would resolve our dependencies properly (without conflicting opencv versions). It would not affect users running uv pip install freemocap.

---

This change makes it so running uv pip install freemocap doesn't download opencv-python. So, you can run in order:

1. uv venv freemocap-env --python 3.11
2. source freemocap-env/bin/activate
3. uv pip install freemocap
4. freemocap

And have freemocap run without the opencv conflict.

This will get us a non-pyapp based installation option that avoids the opencv conflict entirely, at the cost of substituting uv venv for conda create and uv pip install for pip install.

Currently not working as intended - I'm going to dig into this further and possibly file an issue with uv. (EDIT: I filed an issue here: astral-sh/uv#9073) It works great using uv pip install -e., and if we can get it to work properly with uv pip install freemocap, it will be worth changing our default installation method to uv.

Testing

• with uv pip install -e.: when installing from within the project folder, this works as intended!
• with uv pip install 'freemocap @ /Users/philipqueen/Documents/GitHub/freemocap/': when installing from disk (with the correct branch active), this doesn't work. opencv-python is still downloaded.
• with uv pip install "git+https://github.com/freemocap/freemocap@philip/use_uv": when installing from git (on the correct branch), this doesn't work. opencv-python is still downloaded.

[philipqueen]

It looks like (based on the uv issue linked above) this feature can't easily go into the packaged metadata - i.e. there's no way this setting will work when users pip or uv pip install freemocap.

I would still support adding the override flag, so that in development we can add uv pip install -e. and not have to deal with the conflict, but maybe continuing to deal with the conflict is a good motivator towards better installation methods (these are also discussed a bit in the uv issue)