feat: Make True and False branches unconditional

[mark-koch]

For example, when building a CFG for if True: ..., build an unconditional branch. This improves linearity checking for functions involving while True loops, since dataflow analysis now understands that such loops can only exit on an explicit break or return.

It also means that Guppy is now better at detecting unreachable code. For now, we error out in this case, but in the future it would be nice to only emit a warning (see #739).

One complication introduced by this is that Guppy can now generate CFGs where the exit block is unreachable. This lead to some problems with borrowed variables. This edge case now needs to be specially handled.

I recommend reviewing each of the three commits separately

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 97.95918% with 1 line in your changes missing coverage. Please review.

Project coverage is 92.84%. Comparing base (647ad3d) to head (8a30da1).

Files with missing lines	Patch %	Lines
guppylang/cfg/builder.py	94.11%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #740      +/-   ##
==========================================
+ Coverage   92.81%   92.84%   +0.02%     
==========================================
  Files          71       71              
  Lines        8159     8200      +41     
==========================================
+ Hits         7573     7613      +40     
- Misses        586      587       +1     

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

[mark-koch]

Arguably, this shouldn't be an error since non-terminating functions technically cannot leak. However, it would be difficult to generate valid Hugr for cases like this, e.g.

while True:
    qubit()

Therefore, I think it's ok to still complain about leaks, even if the function provably doesn't terminate

[aborgna-q]

Uhm, I don't think erroring out on unreachable code is a good option.
Is there no alternative asides from implementing warnings? Even completely ignoring the unreachable code may be better.

Adding if False and ..., mid-point returns, and unused branches is something to be expected while coding and testing things. These errors would make development a lot more annoying.