Ref count optimizations and some bug fixes

[bettinaheim]

This PR switches to apply ref count changes only to the outer container and not the inner items unless the ref count changes are due to an assignment to a mutable variable. The reasoning is that I believe it is not possible for an inner item to ever go out of scope earlier than the container unless it is assigned to a mutable variable somewhere.

This PR makes the adjustment in #859 unnecessary (i.e. incorrect), and fixes #970. I believe it may also possibly fix some of #981 (tbd, I think there are possibly multiple issues there).

[swernli]

The test QIR looks good and the logic is sound, so approving. We will have to rely on manual testing for runtime behavior for now.

[bettinaheim]

The test QIR looks good and the logic is sound, so approving. We will have to rely on manual testing for runtime behavior for now.

Yes, I did some manual validation locally, but of course not nearly as extensive as a proper CI setup should be - let's push to get the full CI up and running.

[bettinaheim]

Very briefly outlining the issue that this PR ran into and that I overlooked initially:
In order to ensure that a value stays alive when you return it, the ref counts for e.g. tuples and their items is 1 (so far so good), and the idea is that the calling function then releases them recursively. That is implemented this way with this PR and ok so far. The issue now is when we have a copy-and-update expression involving that. If that's the case, then we run into the same issue as described in #859; I had removed the adjustment introduced in 859, because I had thought it would no longer be necessary (or correct for that matter), which is incorrect.