Add pretty printing for statevectors and density matrices

[simsaidan]

First, implements function that pretty prints a complex number. Then, adds to statevecotr and density matrix. The density matrix is printed in matrix form.

Resolves #501 as part of UnitaryHack.

Before submitting, please check the following:

• Make sure you have tests for the new code and that test passes (run nox)
• If applicable, add a line to the [unreleased] part of CHANGELOG.md, following keep-a-changelog.
• Format added code by ruff
  • See CONTRIBUTING.md for more details
• Make sure the checks (github actions) pass.

Then, please fill in below:

Context (if applicable):

Description of the change:

Related issue:

[codecov]

Codecov Report

❌ Patch coverage is 92.99363% with 11 lines in your changes missing coverage. Please review.
✅ Project coverage is 88.94%. Comparing base (fcdb8f4) to head (82bef3d).
⚠️ Report is 1 commits behind head on master.

Files with missing lines	Patch %	Lines
graphix/pretty_print.py	92.71%	11 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #523      +/-   ##
==========================================
+ Coverage   88.85%   88.94%   +0.08%     
==========================================
  Files          49       49              
  Lines        7135     7288     +153     
==========================================
+ Hits         6340     6482     +142     
- Misses        795      806      +11     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[thierry-martinez]

Thank you very much for your contribution!

Codecov has detected that some parts of your code are not tested.

As you may have noticed, PR #503 and PR #524 address the same issue (#501). We invite you to cross‑review each other's work: PR reviews are an inherent part of software development, just as important as writing code. Moreover, this review process will help you position your PR relative to the others, allowing us to determine which contribution best addresses the issue.

[thierry-martinez]

The issue description indicates that e and i should be typeset with \mathrm.

[thierry-martinez]

Shouldn't we write: « sqrt(2)/4e^(ipi/4)} »?
It would look better without a space between the coefficient and the imaginary unit.

[simsaidan]

Hey @thierry-martinez ! Thank you for the feedback. I added in \mathrm for e and i. For imaginary numbers, I now format them as 2i or .43i (without the space for integer or decimal factors), or 3i/4 for fractional. Would that work?

I also added tests to improve coverage.

[Vinny010]

Hi @simsaidan — looking through this per @thierry-martinez's nudge. Some observations:

Nice to see the docs additions in visualization.rst and the _ENCODING = Literal["LSB", "MSB"] alias — both worth adopting regardless of which PR lands.

Two technical notes:

• Performance of _real_scalar_to_str: it does a nested loop over (1..max_radicand) × (1..max_denominator) (with the defaults, ~10k iterations per call, and per amplitude). A square-then-rationalize approach — approximate x² as Fraction(x*x).limit_denominator(max_denominator) and decompose the result into a squarefree inner and a rationalized outer — is O(1) in the matching and avoids the brute-force scan.
• _validate_output_format uses assert; under python -O asserts are stripped, so input validation should ideally use an explicit if/raise.