Move to a pixi-based installation

[hameerabbasi]

Disdvantages:

• You lose the venv folder and the ability to mess with it as needed.
• You lose pip and the "regular" way of installing packages.
• CLI users will be affected.
  • Will need to run something like ./launch-ot.sh ... instead of python ...
• source venv/bin/activate is replaced by eval "$(pixi -e [cpu|cuda|rocm] shell-hook)" or prefixing each command with pixi run -e [cuda|rocm|cpu]
• All deps need to be in the TOML. We'd need to make a decision to keep or delete the requirements*.txt files, and if we keep, they have to be kept in sync with the TOML.

Advantages:

• If you have pixi, you can run pixi run -e [cuda|rocm|cpu] <command>, it will take care of installation running the command from beginning to end.
  • Caveat: You'd still have to do env detection (i.e. detecting between CUDA, ROCm and CPU), but wrapping the script is a lot easier.
• All your intermittent deps are fixed as well as the direct deps inside pixi.lock. Works wonders for reproducibility. To update, just use pixi update.
• You can add libgl and tk for linux: No more need for sudo anymore, only hard dep is either wget or curl.
• Installation is MUCH faster. This makes creating a docker image or updating a container easy and fast.
• Installation/launch scripts can be simplified.

Decisions to make:

• Keep or remove requirements*.txt

ToDos for this PR:

• Update the install/run scripts to install/detect pixi and then do pixi install -e ... or pixi run -e ... (or we can get rid of the install script entirely).
• Update CLI docs

After merging:

• Publish a new Docker image ASAP to avoid breakages, especially if removing requirements*.txt.

[hameerabbasi]

@dxqb As promised, the +/- are in the description of the PR.

[hameerabbasi]

This is now blocked on prefix-dev/pixi#1259.

[hameerabbasi]

prefix-dev/pixi#1259 was resolved via prefix-dev/pixi#5241 and included in https://github.com/prefix-dev/pixi/releases/tag/v0.63.0