Format floating-point values in the Rust circuit drawer

[eliarbel]

This commit adds formatting functionality to render floating-point values (e.g. rotation angles) in a way similar to the g formatting flag in Python.

This PR addresses item 3 in #15849

Details and comments

For example, this results in an output like this:

global phase: 6.0168
      ┌────────────┐ ┌────────────┐ ┌───────────────┐
q_0: ─┤ Rx(1.2346) ├─┤ Rx(123.46) ├─┤ Ry(1.23456*ϕ) ├
     ┌┴────────────┴┐├────────────┴┐├───────────────┤
q_1: ┤ Rz(1.2346e8) ├┤ Rx(0.12346) ├┤ Rx(1.2346e-5) ├
     └──────────────┘└─────────────┘└───────────────┘

instead of:

global phase: 6.0168146928204145
     ┌──────────────┐ ┌──────────────┐  ┌───────────────┐
q_0: ┤ Rx(1.234567) ├─┤ Rx(123.4567) ├──┤ Ry(1.23456*ϕ) ├──
     ├──────────────┴┐├──────────────┴┐┌┴───────────────┴─┐
q_1: ┤ Rz(123456789) ├┤ Rx(0.1234567) ├┤ Rx(0.0000123456) ├
     └───────────────┘└───────────────┘└──────────────────┘

[qiskit-bot]

One or more of the following people are relevant to this code:

• @Qiskit/terra-core

[Cryoris]

Thanks, this output is much more legible! I left some comments below.

[Cryoris]

Are we testing anywhere that this can be called multiple times? Looking at the code it seems that a new formatter is instantiated every time when we call .format.

[eliarbel]

While I did call one formatter multiple times while I was testing this manually, I thought that since the crate is built around the notion of using a static buffer anyway, it's not worth to add explicit tests for that and that we can just go with the other circuit output tests which for the formatting aspect itself.
That said, I've added such test anyway in d9c2307 since a) it woudln't hurt and b) I want to extend it after #15917 is merged to have a test which covers both $\pi$-based formatting and decimal formatting.

[Cryoris]

What do you think of making the formatter an attribute of the TextDrawer? That would allow us to easily expose this as config later on, and allows to only allocate the buffer once and reuse it (ok likely an unnecessary optimization, but still haha)

[eliarbel]

I thought about it while implementing this and decided to skip it for now. Most of the functions in TextDrawer are associative but should be instance methods IMO to make the code more idiomatic, but I would defer this to a different PR. I still wrote the formatter as a struct instead of a simple function though to allow easy reuse of the buffer in case this will ever become a bottleneck, but for now I went with the more straightforward usage of instantiating and calling it on-the-fly.
Regarding performance, TBH, there are a lot of performance and memory optimization opportunities in the Rust circuit writer, but I think for now, besides functionality, the major consideration with the writer should be readability and easy extendibility.

[Cryoris]

Ok sounds good to me. Since we also are testing now that the re-usable buffer works, I'm good deferring this 👍🏻

[eliarbel]

@Cryoris FYI: I'm putting this on hold for now until #15917 is merged since I would like to incorporate the $\pi$-formatting logic of the other PR inside F64UiFormatter.

[eliarbel]

@Cryoris this is now rebased on top of main to include the $\pi$-formatting functionality of #15917. I'd appreciate it if you can give it another look.

[Cryoris]

Just one question, otherwise LGTM! It might be nice to expose the number of significant bits as option at some point in the future, but I'm favor of the short 5-digits for drawing as default.

[eliarbel]

It might be nice to expose the number of significant bits as option at some point in the future, but I'm favor of the short 5-digits for drawing as default.

I'm thinking it might be nice to split the code into several files which should reside in their own sub-directory. Especially with #16063 which is going to add a lot of code relatively. Once this is done, we can put the formatter in its own file (or in a general utils file) and generalize it more, including having that parameter accept Option